আমি রসিকভাবে প্রশ্নের শিরোনাম করেছি কারণ আমি নিশ্চিত যে "এটি নির্ভর করে" তবে আমার কিছু নির্দিষ্ট প্রশ্ন রয়েছে।
নির্ভরযোগ্যতার অনেক গভীর স্তর রয়েছে এমন সফ্টওয়্যারে কাজ করা, আমার দলটি প্রতিটি কোড মডিউলটিকে নীচের নির্ভরতা থেকে পৃথক করতে মোটামুটিভাবে বিদ্রূপের ব্যবহার করতে অভ্যস্ত হয়ে উঠেছে।
অতএব আমি অবাক হয়ে গিয়েছিলাম যে রায় ওশেরোভ এই ভিডিওতে পরামর্শ দিয়েছেন যে আপনারা কেবল সময়ের 5% এর মতো কিছু উপহাস করা উচিত। আমি অনুমান করি যে আমরা 70-90% এর মধ্যে কোথাও বসে আছি। আমি সময়ে সময়ে অন্যান্য অনুরূপ দিকনির্দেশনাও দেখেছি ।
আমার দুটি বিষয় "ইন্টিগ্রেশন টেস্ট" হিসাবে বিবেচনা করা উচিত যা এগুলি স্বতন্ত্রভাবে পৃথক পৃথক নাম দেওয়া উচিত: 1) প্রক্রিয়া পরীক্ষা যা একাধিক কোড মডিউলগুলিকে একীভূত করে এবং 2) প্রক্রিয়াজাতকরণ পরীক্ষা যা কথা বলে ডাটাবেস, ফাইল সিস্টেম, ওয়েব পরিষেবাদি ইত্যাদিতে এটি টাইপ # 1 যা আমার সাথে সম্পর্কিত, পরীক্ষাগুলি যা একাধিক কোড মডিউলগুলিকে সমস্ত প্রক্রিয়াতে সংহত করে।
আমি যে সম্প্রদায়ের দিকনির্দেশনা পড়েছি তার বেশিরভাগই পরামর্শ দেয় যে আপনার প্রচুর বিচ্ছিন্ন, সূক্ষ্ম দানা ইউনিট পরীক্ষা এবং কম সংখ্যক মোটা-দানাদার শেষ থেকে শেষ পর্যন্ত সংহতকরণ পরীক্ষা পছন্দ করা উচিত, কারণ ইউনিট পরীক্ষাগুলি ঠিক কোথায় কোথায় তার সঠিক প্রতিক্রিয়া দেয় unit প্রতিক্রিয়াগুলি তৈরি করা যেতে পারে, তবে মোটা পরীক্ষাগুলি, যা সেট আপ করা জটিল, প্রকৃতপক্ষে সিস্টেমটির আরও শেষ থেকে শেষের কার্যকারিতা যাচাই করে।
এটি দেওয়া হয়েছে, কোডের এই পৃথক ইউনিটগুলি বিচ্ছিন্ন করার জন্য বারবার উপহাসের পরিবর্তে বার বার ব্যবহার করা প্রয়োজন বলে মনে হয়।
নিম্নলিখিত হিসাবে একটি বস্তু মডেল দেওয়া:
... এছাড়াও বিবেচনা করুন যে আমাদের অ্যাপ্লিকেশনটির নির্ভরতার গভীরতা আমি এই চিত্রটিতে ফিট করতে পারি না তার থেকে আরও গভীরতর হয়, যাতে 2-4 স্তর এবং 5-13 স্তরগুলির মধ্যে একাধিক স্তর এন থাকে।
আমি যদি ইউনিট # 1-তে কিছু সাধারণ যৌক্তিক সিদ্ধান্ত পরীক্ষা করতে চাই এবং যদি প্রতিটি নির্ভরতা কোড মডিউলে কনস্ট্রাক্টর-ইনজেকশন হয় যা এর উপর নির্ভর করে যেমন, 2, 3, এবং 4 টি মডিউল 1-তে ইনজেক্ট করা কনস্ট্রাক্টর হয় চিত্রটি, আমি বরং 2, 3 এবং 4 এর মক ইনজেকশন করতে চাই।
অন্যথায়, আমার 2, 3, এবং 4 এর কংক্রিট দৃষ্টান্ত তৈরি করতে হবে এটি কিছু অতিরিক্ত টাইপিংয়ের চেয়ে আরও কঠিন হতে পারে। প্রায়শই 2, 3, এবং 4 এর কনস্ট্রাক্টরের প্রয়োজনীয়তা থাকে যা সন্তুষ্ট করা কঠিন হতে পারে এবং গ্রাফ অনুসারে (এবং আমাদের প্রকল্পের বাস্তবতা অনুসারে) এর কনস্ট্রাক্টরদের সন্তুষ্ট করার জন্য আমার 13 এর মাধ্যমে এন এর কংক্রিট ইনস্ট্যান্স নির্মাণ করা প্রয়োজন of 2, 3, এবং 4।
আমার কিছু নির্দিষ্ট উপায়ে আচরণ করার জন্য যখন আমার 2, 3, বা 4 প্রয়োজন হয় তখন এই পরিস্থিতি আরও চ্যালেঞ্জ হয়ে ওঠে যাতে আমি # 1-এ সাধারণ লজিকাল সিদ্ধান্তটি পরীক্ষা করতে পারি। প্রয়োজনীয় উপায়ে আচরণ করতে 2, 3, বা 4 পেতে পুরো অবজেক্ট গ্রাফ / বৃক্ষটি একবারে আমার বুঝতে ও "মানসিকভাবে যুক্তি" লাগতে পারে। এটি myMockOfModule2.Cetup (x => x.GoLeftOrRight ()) করা প্রায়শই সহজ মনে হয় Return রিটার্নস (নতুন রাইট ()); মডিউলটি পরীক্ষার জন্য 1 মডিউলটি প্রত্যাশিত প্রতিক্রিয়া জানায় যখন মডিউল 2 ডানদিকে যেতে বলে।
যদি আমি 2 ... এন ... 13 এর একত্রীকরণের পরীক্ষাগুলি একসাথে পরীক্ষা করি তবে পরীক্ষার সেটআপগুলি খুব বড় এবং বেশিরভাগ নকল হবে। পরীক্ষার ব্যর্থতাগুলি রিগ্রেশন ব্যর্থতার জায়গাগুলি চিহ্নিত করতে খুব ভাল কাজ না করে। টেস্টগুলি স্বাধীন হবে না ( অন্য একটি সহায়ক লিঙ্ক )।
মঞ্জুরিপ্রাপ্ত, মডিউলগুলির খুব কমই আর কোনও নির্ভরতা থাকে বলে মেনে নেওয়া যায়, নীচের স্তরটির পরীক্ষা-নিরীক্ষার চেয়ে বরং ইন্টারঅ্যাকশন-ভিত্তিক, রাজ্য ভিত্তিক করার পক্ষে যুক্তিযুক্ত। তবে মনে হয় যে নীচের অংশের উপরের কোনও মডিউল বিচ্ছিন্ন করার জন্য সংজ্ঞা দিয়ে প্রায় উপহাস করা প্রয়োজন।
এই সমস্ত দেওয়া, কেউ কি আমাকে বলতে পারে আমি কি অনুপস্থিত হতে পারে? আমাদের দল কি উপহাসকে ব্যবহার করে? বা সম্ভবত আদর্শ ইউনিট টেস্টিং গাইডেন্সে কিছু ধারণা রয়েছে যে বেশিরভাগ অ্যাপ্লিকেশনে নির্ভরতার স্তরগুলি যথেষ্ট পরিমাণে অগভীর হবে যে সমস্ত কোড মডিউলগুলি একত্রিত করে পরীক্ষা করা (আমাদের কেসটিকে "বিশেষ" বানানো) সত্যিই যুক্তিসঙ্গত? বা সম্ভবত অন্যভাবে, আমাদের দলটি কি আমাদের সীমানা প্রসঙ্গে পর্যাপ্ত পরিমাণে আবদ্ধ না?
Or is there perhaps some assumption in typical unit testing guidance that the layers of dependency in most applications will be shallow enough that it is indeed reasonable to test all of the code modules integrated together (making our case "special")? <- এই।