আমাদের ইউনিট পরীক্ষাগুলি পরিচালনা করার সর্বোত্তম উপায় কী

Question

আমরা কয়েক বছর ধরে আমাদের মূল প্রোগ্রামের জন্য প্রচুর পরিমাণে ইউনিট পরীক্ষাগুলি তৈরি করেছি। কয়েক হাজার. সমস্যাটি হ'ল আমাদের কাছে পরীক্ষা রয়েছে সে সম্পর্কে আমাদের পরিষ্কার ধারণা নেই কারণ অনেকগুলি রয়েছে। এবং এটি একটি সমস্যা কারণ আমরা জানি না যেখানে আমরা পরীক্ষাগুলিতে দুর্বল (বা যেখানে আমাদের নকল রয়েছে)।

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

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

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

এবং আমরা এই বিভাগগুলি কীভাবে নথি করব, ইউনিট পরীক্ষার নামকরণ করব ইত্যাদি?

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

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

Comments

আপনার প্রশ্নটি সত্যিই মনে হচ্ছে, আমরা কীভাবে জানি যে আমরা একটি নির্দিষ্ট দৃশ্যের পরীক্ষা করেছি?

— অ্যান্ডি উইসেন্ডেঞ্জার

হ্যাঁ! এবং যে কোনও অনাকাঙ্ক্ষিত দৃশ্যের জন্য পরীক্ষাগুলি কোথায়। এবং সেখান থেকে আমরা # 2 প্রয়োজনীয়তা পাই - যা আচ্ছাদিত রয়েছে তা পড়তে আমাদের কী মিস করেছি তা খুঁজে পেতে সহায়তা করে।

— ডেভিড থিলেন

Answer 1

সাধারণত, আমি আমার ইউনিট পরীক্ষার জন্য উত্স বৃক্ষটি আয়না করে দেখি। সুতরাং, আমার কাছে src / lib / fubar থাকলে আমার কাছে একটি পরীক্ষা / lib / fubar থাকত যা ফুবারের জন্য ইউনিট পরীক্ষা ধারণ করে।

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

Comments

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

— ডেভিড থিলেন

যা প্রশ্ন বাড়ে, যেখানে আমরা পরীক্ষার টেবিলটি সংরক্ষণ করি? আমি মূল উত্স ডিরেক্টরিতে একটি স্প্রেডশিট ভাবছি ???

— ডেভিড থিলেন

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

— সারদাথ্রিয়ন - মনিকা

Answer 2

সর্বাধিক সাধারণ কাঠামোটি হ'ল srcএবং testডিরেক্টরি আয়না বলে মনে হচ্ছে ।

src/module/class
test/module/class_test

তবে, একটি বিকল্প কাঠামো আছে যা আমি দেখেছি যা আমি এখন আরও ভাল বলে বিশ্বাস করি।

src/module/class
src/module/class_test

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

Comments

পূর্ববর্তী পদ্ধতির একটি অপূর্ণতা হ'ল প্রতিবার আপনি যখন প্রকল্পের ফাইলের কাঠামো পরিবর্তন করার সিদ্ধান্ত নেবেন তখন আপনাকে পরীক্ষার কাঠামোর জন্য একই কাজ করতে হবে। কোডগুলি যেখানে পরীক্ষা রয়েছে সেখানে এই সমস্যাটির অস্তিত্ব নেই।

— ভিক্টোর 7575

Answer 3

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

Solution
   MyProduct.Project1 (Project)
      Folder1 (Folder)
         ClassAA (Class def)
         ...
      Folder2
         ClassAB
         ...
      ClassAC
      ...
   MyProduct.Project2
      Folder1
         ClassBA
         ...
      ClassBB
      ...
   ...
   MyProduct.Tests.Unit
      Project1
         Folder1
            ClassAATests
            ClassAATests2 (possibly a different fixture setup)
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests
      ...
   MyProduct.Tests.Integration
      Project1 (a folder named similarly to the project)
         Folder1 (replicate the folders/namespaces for that project beneath)
            ClassAATests
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests

ইউনিট-টেস্টিং ফ্রেমওয়ার্কের সাথে কোডেড যে কোনও এএটি বা এইইটিগুলির জন্য, এটি কিছুটা পরিবর্তন করে; সাধারণত এই পরীক্ষাগুলি ধাপগুলির একটি সেটকে মিরর করে, যা কোনও নতুন ব্যবহারের ক্ষেত্রে বা গল্পের কার্যকারিতা পরীক্ষা করে। আমি সাধারণত এই MyProduct.Tests.Acceptanceপ্রকল্পগুলিতে একটি প্রকল্পে এইরকম কাঠামো তৈরি করি , প্রতিটি গল্পের পরীক্ষা দিয়ে, সম্ভবত মাইলফলক বা "মহাকাব্য" গল্পের দ্বারা দলবদ্ধ করা হয় যা বিকাশের অধীনে গল্পটির অন্তর্গত। যাইহোক, সেগুলি সত্যই কেবল উবার-সংহতকরণ পরীক্ষা, এবং তাই যদি আপনি গল্প-ভিত্তিক ফ্যাশনের পরিবর্তে পরীক্ষাগুলিকে আরও অবজেক্ট-ভিত্তিক কাঠামোগত কাঠামো গঠনের পক্ষে পছন্দ করেন তবে আপনার এমনকি কোনও MyProduct.Tests.Acceptanceঅনুরূপ প্রকল্পের প্রয়োজনও হবে না ; MyProduct.Tests.Integrationপরীক্ষার অধীনে সর্বাধিক-স্তরের অবজেক্টের সুযোগে কেবল এটিকে ফেলে দিন ।

Answer 4

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

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

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

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

Comments

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

— ডেভিড থিলেন

Answer 5

আপনি পরীক্ষায় দুর্বল কিনা তা জানার একটি উপায় হ'ল ট্রেসেবিলিটি। সাধারণত পরীক্ষার জন্য, এটি কভারেজের রূপ নেয়।

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