কোডের জন্য ইউনিট পরীক্ষাগুলি লেখার কোনও মূল্য নেই যা ইতিমধ্যে প্রয়োগগুলির উত্তরাধিকার সূত্রে কাজ করে?


27

স্পষ্টতই কিছু পুরানো অ্যাপ্লিকেশনগুলি ইউনিট পরীক্ষার পক্ষে হওয়া বা এটি করা কঠিন নয় কারণ এটি প্রথম স্থানে লেখা হয়েছিল।

তবে জায়গাগুলিতে, কিছু সহায়ক পদ্ধতির মতো যা সম্ভবত ইউনিট পরীক্ষিত হতে পারে, আমি কি তাদের জন্য ইউনিট পরীক্ষা লেখার বিরক্ত করব?

আমার অর্থ, এগুলি একটি কুকুরের মতো লেখা যেতে পারে তবে তাত্ত্বিকভাবে জটিলভাবে ভঙ্গুর হলেও সময়ের পরীক্ষা প্রমাণ করেছে যে এটি যেভাবে করা উচিত ঠিক তেমনভাবে কাজ করে। আমি যদি কেবল পুনরায় ফ্যাক্টরিং বলার জন্যই ইউনিট টেস্টে বিরক্ত করতে পারি বা যখনই সময় পাই আমি কি তাদের জন্য ইউনিট পরীক্ষা লিখি?

এটি করার কোনও মূল্য আছে কি?

এ বিষয়টিও বিবেচনায় রাখুন যে পদ্ধতির সংজ্ঞাটি অস্পষ্ট হতে পারে এবং প্রদত্ত অবস্থায় কিছু পদ্ধতিতে আসলে কী করা উচিত তা নিয়ে আমার গবেষণা করার প্রয়োজন হতে পারে।


4
নিজেকে উপকার করুন এবং উত্তরাধিকারের কোড সহ কার্যকরভাবে কাজ করা পড়ুন । যদি এটি এবং অন্যান্য সম্পর্কিত প্রশ্নের উত্তর দিতে উত্সর্গীকৃত একটি সম্পূর্ণ বই হয়।
রিইন হেনরিচস

উত্তর:


15

আমি মনে করি আপনার অবশ্যই আবেদনের জন্য যতটা সম্ভব পরীক্ষা করা উচিত। তারা আপনাকে কোডবেস শিখতে এবং ইভেন্টের রিফ্যাক্টরিং বা নতুন উন্নয়নের জন্য আপনাকে প্রস্তুত করতে সহায়তা করবে।

সেই দৃশ্যে আপনি কয়েকটি ধরণের পরীক্ষা লিখতে পারেন, তাদের প্রত্যেকের নিজস্ব যোগ্যতা রয়েছে। এই পরীক্ষাগুলি লেখার মাধ্যমে আপনি যে অ্যাপ্লিকেশনটির সাথে व्यवहार করছেন সে সম্পর্কে আপনাকে বিস্তৃত শিক্ষা দেবে।

প্রথমত, আপনি নির্ভুলতার জন্য লেখার পরীক্ষা বন্ধ করার আগে, পরীক্ষা করুন যা বর্তমান আচরণকে ক্যাপচার করে , সেগুলি সঠিক বা ভুল হতে পারে write এটি বেশ সুরক্ষিত বাজি যে আপনি কোণার ক্ষেত্রে বা কোডের কিছু অংশে প্রোগ্রামটি চালনার মাধ্যমে পুরোপুরি পরীক্ষিত হয়নি এমন বাগগুলি উন্মোচন করতে চলেছেন। কোডটি কী করা উচিত তা নিয়ে চিন্তা করবেন না, কেবল এটি কী করে তা ক্যাপচার করুন। আপনি এগিয়ে যাওয়ার সাথে সাথে কোডটি পড়ার বা আউটপুটটি কী হবে তা নির্ধারণের জন্য গুরুতর সময় ব্যয় করার বিষয়ে চিন্তা করবেন না। কেবলমাত্র আপনার পরীক্ষা চালান এবং সেই আউটপুটটিকে একটি জোরে ক্যাপচার করুন।

এটি আপনাকে কোডটি কীভাবে পরিচালনা করে এবং প্রধান ব্যথা পয়েন্ট বা দুর্বল অঞ্চলগুলি কোথায় হতে পারে তার বোঝার একটি শক্ত ভিত্তি দেয়। আপনি যদি বাগগুলি উন্মোচন করেন, তবে আপনি স্থির করার যোগ্য কিনা তা সিদ্ধান্ত নেওয়ার ক্ষমতা নিয়ে লোকদের কাছে যেতে পারেন এবং এই সিদ্ধান্তগুলি নিতে পারেন।

এরপরে, আপনি কয়েকটি বৃহত্তর (স্কোপে) পরীক্ষা লিখতে পারেন যা কোডের এমন কিছু অংশ কভার করে যা সহজেই ইউনিট-টেস্টেবল নাও হতে পারে তবে যেখানে ওয়ার্কফ্লোগুলি যতটা সম্ভব পরীক্ষা করা গুরুত্বপূর্ণ be এই ওয়ার্কফ্লো টেস্টগুলি বা ইন্টিগ্রেশন টেস্টগুলি , আপনি কীভাবে তাদের দেখতে চান তার উপর নির্ভর করে আপনাকে সেই ওয়ার্কফ্লোগুলিকে আরও পরীক্ষামূলক করে তুলতে এবং পুনরুদ্ধার করার জন্য একটি ভাল বেস প্রদান করবে যখন কোনও নতুন বৈশিষ্ট্য যুক্ত করা দরকার যা কোনও বিদ্যমান কর্মপ্রবাহকে প্রভাবিত করতে পারে।

সময়ের সাথে সাথে, আপনি পরীক্ষার একটি স্যুট তৈরি করবেন যা সেখানে আপনার বা পরবর্তী ব্যক্তির সাথে আবেদনটির উত্তরাধিকার সূত্রে শেষ করতে সহায়তা করবে।


13

আমি ইউনিট পরীক্ষাগুলি নিখুঁত পরীক্ষা হিসাবে নয়, নির্দিষ্টকরণ হিসাবে দেখছি। নির্দিষ্ট ক্ষেত্রে আপনি উল্লেখ করেছেন যে আসল মানটি আসবে যখন নতুন স্পেসিফিকেশন অনুসারে কোনও পরিবর্তন করার আগে আপনার ইউনিট পরীক্ষা হবে। আপনি যদি উত্তরাধিকার সূত্রে প্রাপ্ত কোডটি পরিবর্তন করতে চলেছেন তবে আমি দেখতে পাচ্ছি সবচেয়ে ভাল উপায় কার্যকারিতাটির জন্য ইউনিট পরীক্ষা করা, এটি কেবল একটি সুরক্ষা জালই আনবে না তবে সেই নির্দিষ্ট ইউনিটটি কী করবে সে সম্পর্কে আরও স্পষ্টতা আনতে আমাদের সহায়তা করবে। এটি আপনাকে উল্লেখ করে কিছু গবেষণা করতে বাধ্য করতে পারে যা বোঝার জন্য ভাল। সুতরাং আমার গ্রহণটি হল মডিউলের ইউনিট পরীক্ষাটি পরিবর্তিত হওয়ার আগেই জায়গা করে নেওয়া।


কাজ করবে এমন উচ্চ স্তরের ভাষায় পরীক্ষা লিখুন। পরিবর্তন করার সময় অনুমান করতে বলা হলে, অনুপস্থিত পরীক্ষাগুলি লেখার জন্য প্রয়োজনীয় সময় অন্তর্ভুক্ত করুন। পরিবর্তনটি পেতে আপনার আরও বেশি সময় লাগতে পারে তবে আপনি ক্ষেত্রটিতে অনেক কম বাগ লাগিয়ে দেবেন।
কেভিন

8
 > Is there any value in writing unit tests for code that 
 > already works when inheriting applications?

কোন । আমার অভিজ্ঞতা থেকে প্রডাকশন কোডটি লেখার পরে ইউনিট পরীক্ষা লেখার জন্য একটি খারাপ ব্যয় / উপকারের সম্পর্ক রয়েছে কারণ ভারী রিফ্যাক্টরিং ছাড়াই বিচ্ছিন্নভাবে কোডটি পরীক্ষা করার উপায়গুলি খুঁজে পাওয়া যথেষ্ট সম্ভাবনা / কঠিন । পরীক্ষা চালিত বিকাশের অন্যতম সুবিধা হ'ল আপনি স্বচ্ছভাবে সংযুক্ত কোডটি পান। আপনি যদি পরে পরীক্ষাগুলি লিখেন তবে কোডগুলি শক্তভাবে মিশ্রিত হওয়ার সম্ভাবনা বেশি।

হ্যাঁ আপনি যে ফাংশনগুলিতে পরিবর্তন করার পরিকল্পনা নিয়েছেন সেই অ্যাপ্লিকেশনটির জন্য আপনি ইন্টিগ্রেশন পরীক্ষা লিখতে পারেন। আপনার পরিবর্তনগুলি কিছু ভঙ্গ করে কিনা তা দেখার জন্য আপনি এইভাবে রিগ্রেশন-পরীক্ষা করতে পারেন।

হ্যাঁ গুণমান এবং বিকাশকারী দৃষ্টিকোণ থেকে এটি পরীক্ষা করা মূল্যবান।

ব্যবসায়ের দিক থেকে কোনও নয় কারণ সত্যিকারের ব্যবসায়ের মূল্য না পাওয়ার জন্য আপনার সময় / অর্থের প্রয়োজন এমন গ্রাহককে বিক্রয় করা খুব কঠিন কিন্তু অস্পষ্ট প্রতিশ্রুতি যে ব্যবসায়-পরিবর্তনগুলি খারাপ করবে না।


এই ক্ষেত্রে ইউনিট পরীক্ষার পরিবর্তে ইন্টিগ্রেশন পরীক্ষার জন্য +1। খুব ব্যবহারিক পরামর্শ
gbjbaanb

5

যদি সম্ভব হয় তবে বিদ্যমান কোডের জন্য টেস্ট লেখার আরও বেশি কারণ আছে যা "ইতিমধ্যে কাজ করে"। যদি কোনও পরীক্ষা না থাকে তবে সম্ভাবনা হ'ল কোডটি গন্ধযুক্ত পাকা হয় এবং উন্নত করতে ব্যাপক রিফ্যাক্টরিং ব্যবহার করতে পারে; পরীক্ষার স্যুট আপনাকে রিফ্যাক্টর করতে সহায়তা করবে। এটি এমনকি প্রকাশ করতে পারে যে মূল কোডটি সঠিকভাবে কাজ করে না ; আমি একবার স্মরণ করেছিলাম যখন আমি বিক্রয় রিপোর্ট তৈরির পদ্ধতির জন্য পরীক্ষা লিখেছিলাম এবং আমি দেখেছি এটি সঠিকভাবে জিনিস গণনা করছে না তাই বিক্রয়গুলি তাদের প্রকৃত তুলনায় কয়েক হাজার ডলার বেশি ছিল এবং পাঁচ বছরেও কেউ জানতে পারেনি যে কোডটি উত্পাদনে ছিল (ভাগ্যক্রমে এটি জিনিসগুলির আসল আর্থিক শেষ ছিল না, কেবল বিক্রয় প্রতিবেদনের অনুমান)।

অবশ্যই, এই পরামর্শটি কেবল তখনই প্রযোজ্য যদি আপনি প্রকৃতপক্ষে পরীক্ষা লিখতে পারেন । আমার অভিজ্ঞতায়, পরীক্ষাগুলি ছাড়াই একটি কোডবেস পরীক্ষাগুলি পুনরুদ্ধার করা প্রায় অসম্ভব কারণ আপনাকে প্রথমে পরীক্ষার সমর্থনের জন্য যথেষ্ট বিমূর্ত হতে কোড মডিউলগুলির অর্ধেকটি আবার লিখতে হবে, এবং আপনি এটি করতে সক্ষম হবেন না।


সত্য কথা বলার জন্য কেন ডাউনটা?
ওয়েন মোলিনা

4

একেবারে হ্যাঁ , কারণ ইউনিট পরীক্ষাগুলি যথার্থতা যাচাই করা উচিত নয় তবে সিস্টেমের আসল আচরণকে বৈশিষ্ট্যযুক্ত করে। বিশেষত একটি উত্তরাধিকার প্রকল্পের সাথে, প্রয়োজনীয়তার অনেকগুলি প্রকৃত আচরণে স্পষ্টভাবে এনকোড করা হয়।

এই বৈশিষ্ট্য কার্যকারিতা একটি বেসলাইন হিসাবে কাজ করে। এমনকি যদি ব্যবসায়ের দৃষ্টিকোণ থেকে আচরণটি ভুল হয় তবে আপনি আচরণকে আরও নিকৃষ্টতর করে তুলুন। কোনও উত্তরাধিকার প্রকল্পে ক্রেশন অর্জন করা কঠিন হতে পারে এবং এটি আপনাকে একটি বেসলাইন দেয় যাতে আপনি পরিস্থিতি আরও খারাপ না করেই এগিয়ে যেতে পারেন।

সুতরাং, আপনি যে ইউনিট পরীক্ষা করতে পারেন তা লিখুন। যে কোডটি পরীক্ষা করা যায় না তার জন্য কোডটি "সিমগুলি" প্রবর্তন করে আপনার কোডটিকে নির্ভরতা পৃথক করতে আপনার কোডটিকে রিফ্যাক্টর করুন - আপনি যে কোডটি পরীক্ষা করতে চান না সেই কোড থেকে আপনি যে কোডটি পরীক্ষা করতে চান তা আলাদা করতে পারেন locations

চরিত্রায়ন পরীক্ষা এবং সিম হিসাবে ইউনিট পরীক্ষার ধারণাগুলি মাইকেল ফেদারস দ্বারা লিগ্যাসি কোড সহ কার্যকরভাবে কাজ করার মূল পয়েন্ট , আমি যে বইটি অত্যন্ত সুপারিশ করি।


2

আমি নিজেই এ সম্পর্কে চিন্তাভাবনা করেছি কারণ এখানে প্রচুর পরিমাণে বিনা দলিলভাবে খারাপভাবে লেখা হয়েছে, তবে আমাদের সিস্টেমে ওয়ার্কিং লেগ্যাসি কোড রয়েছে।

আপনি একটি সূক্ষ্ম বিন্দু করুন:

আমি যদি কেবল পুনরায় ফ্যাক্টরিং বলার জন্যই ইউনিট টেস্টে বিরক্ত করতে পারি বা যখনই সময় পাই আমি কি তাদের জন্য ইউনিট পরীক্ষা লিখি?

প্রয়োজনীয়তাগুলি পরিবর্তিত হলে আমি মনে করি এটি ইউনিট পরীক্ষাগুলি লিখতে সর্বাধিক মূল্যবান হবে। না হলে আমি বিরক্ত করব না বিশেষত যেহেতু আপনি যথাযথ পরীক্ষা লিখতে পারবেন না, কারণ আপনি সমস্ত শর্ত জানেন না।

আমার কখন সময় আছে?

আপনার কাছে সময় আছে যখন এটি অগ্রাধিকার প্রাপ্ত হবে, তাই না? সুতরাং এটি কখনই ঘটবে না। :)


1

আপনি কি সেই কোডবেসের যে দিকগুলি আগে কোনও প্রোডাকশন অ্যাপ্লিকেশনটিতে ব্যবহার করেননি সেগুলি উত্থাপন করার চেষ্টা করছেন? প্রথমে সেই পরিস্থিতিতেগুলির জন্য ইউনিট পরীক্ষা লিখুন। আপনাকে এখানে আপনার কাজের অগ্রাধিকার দিতে সক্ষম হতে হবে এবং আমি মনে করি যে আর্ট অফ ইউনিট টেস্টিংয়ের সেই বিষয়ে কিছু পরামর্শ ছিল (বিশেষত কীভাবে উত্তরাধিকারের কোডবেসগুলির পরীক্ষার জন্য যেতে হবে)।


1

কেবলমাত্র অ্যাপ্লিকেশনটি চালু এবং চলমান থাকায় সবকিছুই কাজ করছে বলে ধরে নিবেন না ... সাধারণত, "সময়ের পরীক্ষা" কেবলমাত্র দেখায় যে ক) আপনি এখনও বাকি ত্রুটিগুলি খুঁজে পান নি বা খ) যে ব্যক্তিরা খুঁজে পেয়েছেন তারা তাদের রিপোর্ট করে নি। (অথবা সম্ভবত উভয়ই।) এমনকি কোডগুলি যা সম্ভবতঃ এখন কাজ করছে তা পরবর্তী সময় আপনাকে পরিবর্তন করতে হবে না।

ইউনিট পরীক্ষাগুলি আপনাকে নিশ্চিত করে তোলে যে নির্দিষ্ট কার্যকারিতা অক্ষত রয়েছে এবং যুক্তিসঙ্গত পরিমাণের ক্ষেত্রে এটি প্রদর্শন করার উপায়ও সরবরাহ করে। এমনকি একক বাগ ফিক্সের জন্যও "আশেপাশে এটি পরীক্ষা করুন এবং এটি পরীক্ষা করুন" এর চেয়ে এটি গুরুত্বপূর্ণ more (আশেপাশে কব্জি করা ইন্টিগ্রেশন বা সিস্টেম টেস্টিংয়ের সমতুল্য, সুতরাং সেই অর্থে, ম্যানুয়ালি অ্যাপ্লিকেশনটি পরীক্ষা করা একক পরীক্ষার চেয়ে বেশি কভার করতে পারে, তবে এটি এখনও একটি অদক্ষ পদ্ধতিতে সময় ব্যয় করে tests এমনকি এই পরীক্ষাগুলিকে স্বয়ংক্রিয় করার কিছু পদ্ধতিও রয়েছে ম্যানুয়ালি এগুলি করার চেয়ে ভাল)

আপনি কোড পরিবর্তন করার সময় অবশ্যই পরীক্ষাগুলি লিখতে হবে, এটি ফিক্সিং বা রিফ্যাক্টরিং কিনা। আপনি যেমন পরীক্ষা করতে পারেন তেমনই ভাল করতে পারেন, যদি পরের বারে কোনও ত্রুটি ঠিক করতে হয় (এবং পরবর্তী সময়ও আসবে) কিছুটা সময় বাঁচানো ছাড়া অন্য কোনও কারণে না হয় ... যদিও এই ক্ষেত্রে, আপনি যে সফ্টওয়্যারটি সর্বদা ত্রুটিমুক্ত থাকে এবং এইভাবে ভবিষ্যতের রক্ষণাবেক্ষণের জন্য ব্যয় করা সময় "নষ্ট" হয় এমন লোকদের প্রত্যাশার বিপরীতে সেই সময়টিকে ভারসাম্য বজায় রাখতে হবে। (যদিও এর অর্থ এই নয় যে আপনার বর্তমান সময়সূচিগুলি উপেক্ষা করা উচিত।) যদি আপনি এটি করেন তবে আপনার পর্যাপ্ত কভারেজ থাকবে যা আপনি উত্তরাধিকার অ্যাপ্লিকেশনগুলিতে পরীক্ষার মান প্রদর্শন করতে শুরু করতে পারেন এবং এটি আপনাকে ব্যয় করতে সহায়তা করতে পারে ভবিষ্যতের অ্যাপ্লিকেশনগুলিতে সেই সময়টি, যা শেষ পর্যন্ত উত্পাদনশীল বিকাশে ব্যয় করার জন্য সময় মুক্ত করে দেওয়া উচিত।


0

আমার লালা-স্থল হৃদয় থেকে, আমি হ্যাঁ বলব এবং কেবল এটিই নয়, তবে এটি হ্যাক করুন, এটি রিফেক্টর করুন এবং পরীক্ষা চালিয়ে যান, তবে নিশ্চিত হন যে আপনি অন্যান্য গুরুত্বপূর্ণ প্রকল্পে পিছিয়ে নেই। একজন কর্মরত প্রোগ্রামার হিসাবে, যদি আপনার কাজ ঝুঁকিতে থাকে বা কোনও পরিচালক যদি আপনাকে মালিকানা নিতে বলেছিলেন, তবে হ্যাঁ। যদি দল বা সংস্থা ক্ষতিগ্রস্থ হতে পারে, তবে কোম্পানিকে দুর্যোগ থেকে বাঁচাতে টেস্টিং করা জরুরি কিনা তা জানাতে আপনার ম্যানেজারের সাথে আলোচনা করুন। যদি তিনি বলেন যে চিন্তা করবেন না, তবে আপনি হুকের বাইরে রয়েছেন (অগত্যা নয়, দোষী প্রতিনিধিদল হ'ল একটি দক্ষ দক্ষতা, তাই নিশ্চিত হন যে আপনি হুকের বাইরে আছেন ... সত্যই!)

শুভকামনা!

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.