দরকারী ইউনিট পরীক্ষা কি তা নির্ধারণ করা হচ্ছে


46

আমি phpunit এর ডক্স দিয়ে যাচ্ছি এবং নিম্নলিখিত উদ্ধৃতিটি জুড়ে এসেছি:

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

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

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

তার গুরুত্বপূর্ণ বিভাগটি হ'ল

* এবং আপনার প্রতিটি পদ্ধতির নিজস্ব পরীক্ষা পদ্ধতি (1-1 সম্পর্কের ক্ষেত্রে) দিয়ে পরীক্ষা করার চিন্তাভাবনা হাস্যকর হবে। *

সুতরাং যদি প্রতিটি পদ্ধতির জন্য একটি পরীক্ষা তৈরি করা হয় 'হাস্যকর', আপনি / পরীক্ষার জন্য যা লেখেন তা আপনি / কখন বেছে নিলেন?


5
এটি একটি ভাল প্রশ্ন, তবে আমি বিষয় এটি একটি প্রোগ্রামিং ভাষার স্বাধীন প্রশ্ন - আপনি এটি পিএইচপি কেন ট্যাগ করেছিলেন?

এখানে কিছু ভাল নিবন্ধ রয়েছে যা আমাকে কোন ইউনিট পরীক্ষাগুলি লিখতে হবে এবং কোন ক্ষেত্রগুলির জন্য স্বয়ংক্রিয় পরীক্ষাগুলি সরবরাহ করার জন্য গুরুত্বপূর্ণ সেগুলি সম্পর্কে আমাকে একটি ভাল দিকনির্দেশ সরবরাহ করেছে। - blog.stevensanderson.com/2009/11/04/… - blog.stevensanderson.com/2009/08/24/… - ayende.com/blog/4218/scenario-driven-tests
কেন

উত্তর:


26

পদ্ধতি প্রতি কত পরীক্ষা?

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

আপনি উদ্ধৃতি:

* এবং আপনার প্রতিটি পদ্ধতির নিজস্ব পরীক্ষা পদ্ধতি (1-1 সম্পর্কের ক্ষেত্রে) দিয়ে পরীক্ষা করার চিন্তাভাবনা হাস্যকর হবে। *

এবং তারপরে জিজ্ঞাসা করুন:

সুতরাং যদি প্রতিটি পদ্ধতির জন্য একটি পরীক্ষা তৈরি করা হয় 'হাস্যকর', আপনি / পরীক্ষার জন্য যা লেখেন তা আপনি / কখন বেছে নিলেন?

তবে আমি মনে করি আপনি এখানে লেখককে ভুল বুঝেছেন:

থাকার ধারণা one test methodপ্রতি one method in the class to testকি লেখক কল "হাস্যকর" হয়।

(কমপক্ষে আমার জন্য) এটি 'কম' সম্পর্কে নয় 'এটি আরও' সম্পর্কে

সুতরাং আমি তাকে বোঝার মতো আমাকে পুনরায় মন্তব্য করতে দাও:

এবং আপনার প্রতিটি পদ্ধতির একমাত্র পদ্ধতির সাথে পরীক্ষা করার চিন্তাভাবনা (1-1 টির সম্পর্কের ক্ষেত্রে এটির নিজস্ব পরীক্ষা পদ্ধতি) হাস্যকর হবে।

আপনার উদ্ধৃতি আবার উদ্ধৃত করতে:

আপনি যখন বুঝতে পারবেন যে এটি সমস্ত আচরণ নির্দিষ্টকরণ এবং পরীক্ষা না লেখার বিষয়ে, তখন আপনার দৃষ্টিভঙ্গি স্থানান্তরিত হয়।


আপনি যখন টিডিডি অনুশীলন করেন তখন আপনি ভাবেন না :

আমার একটি পদ্ধতি রয়েছে calculateX($a, $b);এবং এর জন্য একটি পরীক্ষা দরকার testCalculcateXযা পদ্ধতি সম্পর্কে সমস্ত কিছুর পরীক্ষা করে।

টিডিডি আপনাকে যা বলে তা হ'ল আপনার কোডটি কী পছন্দ করবে সে সম্পর্কে চিন্তা করা :

আমার দুটি মানের চেয়ে বড় গণনা করা দরকার ( প্রথম পরীক্ষার কেস! ) তবে $ a যদি শূন্যের চেয়ে ছোট হয় তবে এটির একটি ত্রুটি তৈরি করা উচিত ( দ্বিতীয় পরীক্ষার কেস! ) এবং যদি $ বি শূন্যের চেয়ে ছোট হয় তবে .... ( তৃতীয় পরীক্ষার কেস! ) ইত্যাদি on


আপনি প্রসঙ্গ ছাড়া একক পদ্ধতি নয়, আচরণগুলি পরীক্ষা করতে চান।

এইভাবে আপনি একটি টেস্ট স্যুট পান যা আপনার কোডের জন্য নথিভুক্তি এবং এটি যা করার প্রত্যাশা করে তা অবশ্যই ব্যাখ্যা করে, সম্ভবতঃ কেন :)


আপনি নিজের কোডটির কোন অংশটির জন্য ইউনিট পরীক্ষা তৈরি করবেন তা স্থির করে কীভাবে যাবেন?

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

আপনার যদি এটির জন্য পরীক্ষা না করে থাকে তবে কোডটি পরিবর্তন করা আরও শক্ততর (আরও ব্যয়বহুল) হয়ে যায়, বিশেষত যদি এটি আপনি পরিবর্তন করেন না।

টিডিডি হ'ল এটি নিশ্চিত করার একটি উপায় যে আপনার কাছে সমস্ত কিছুর জন্য পরীক্ষা রয়েছে তবে যতক্ষণ আপনি পরীক্ষাগুলি ভাল করে লিখেছেন ততক্ষণ তা ঠিক আছে। সাধারণত একই দিনে সেগুলি লেখার ফলে যেহেতু আপনি পরে এটি করতে যাচ্ছেন না, আপনি তাই না? :)



মন্তব্যের প্রতিক্রিয়া:

পদ্ধতিগুলির একটি শালীন পরিমাণ নির্দিষ্ট প্রসঙ্গে পরীক্ষা করা যায় না কারণ তারা হয় নির্ভর করে বা অন্য পদ্ধতির উপর নির্ভরশীল

ঠিক আছে যে তিনটি জিনিস এই পদ্ধতিগুলি কল করতে পারে:

অন্যান্য শ্রেণীর পাবলিক পদ্ধতি

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

* সুরক্ষিত বা ব্যক্তিগত পদ্ধতি একই *

কোনও শ্রেণীর পাবলিক এপিআইয়ের অংশ নয় এমন কোনও কিছুই সাধারণত পরীক্ষিত হয় না।

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

একই ক্লাসে পাবলিক পদ্ধতি

এটি প্রায়শই ঘটে না তাই না? এবং যদি এটি নীচের উদাহরণে পছন্দ করে তবে এটি পরিচালনা করার কয়েকটি উপায় রয়েছে:

$stuff = new Stuff();
$stuff->setBla(12);
$stuff->setFoo(14);
$stuff->execute(); 

সেটটারগুলি উপস্থিত রয়েছে এবং এক্সিকিউট পদ্ধতিটির স্বাক্ষরের অংশ নয় এটি অন্য একটি বিষয়;)

আমরা এখানে যা পরীক্ষা করতে পারি তা হ'ল যদি আমরা ভুল মানগুলি সেট করি তখন কার্যকর হয়। যে setBlaএকটি ব্যতিক্রম ছোঁড়ার যখন আপনি পাস একটি স্ট্রিং আলাদাভাবে পরীক্ষা করা সম্ভব কিন্তু আমরা পরীক্ষা করতে চান তাহলে ঐ দুই অনুমতি মান (12 & 14) না না পরীক্ষা ক্ষেত্রে চেয়ে (কারনের জন্য) কাজ একসাথে না।

আপনি যদি একটি "ভাল" টেস্ট স্যুট চান তবে পিএইচপি, সম্ভবত (!) @covers Stuff::executeআপনি এই পদ্ধতির জন্য কেবল কোড কভারেজ তৈরি করেছেন তা নিশ্চিত করার জন্য একটি টীকা যোগ করতে পারেন এবং কেবল সেটআপ থাকা অন্যান্য স্টাফগুলি পৃথকভাবে পরীক্ষা করা দরকার (আবার, যদি তুমি ওইটা চাও).

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


* দ্রষ্টব্য: প্রশ্নটি এসও থেকে স্থানান্তরিত হয়েছিল এবং প্রাথমিকভাবে পিএইচপি / পিএইচপিউনিট সম্পর্কে ছিল, তবে নমুনা কোড এবং রেফারেন্সগুলি পিএইচপি ওয়ার্ল্ড থেকে আসে কেননা, আমি মনে করি এটি অন্যান্য ভাষার ক্ষেত্রেও প্রযোজ্য কারণ phpunit অন্যান্য xUnit এর চেয়ে আলাদা নয় doesn't পরীক্ষার ফ্রেমওয়ার্ক।


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


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

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

3
আমি মনে করি যে টিডিডি-র আমি দেখেছি তার সেরা উদাহরণ যা পরীক্ষার কেসগুলি কীভাবে লিখতে হয় তা ক্লিক করতে সহায়তা করেছিল আঙ্কেল বব মার্টিনের বোলিং গেম কাটা। slideshare.net/lalitkale/bowling-game-kata-by-robert-c-martin
Amy Anuszewski

2

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

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

দ্বিতীয় ইউনিট টেস্টগুলি সত্যই তাদের নিজের মধ্যে আসে যখন আমরা রিফ্যাক্টর করি। আমরা আমাদের বাস্তবায়ন পরিবর্তন করি তবে উত্তরগুলি একই থাকে বলে আশা করি - ইউনিট টেস্ট হ'ল আমাদের ইন্টারফেস চুক্তি ভঙ্গ করার বিরুদ্ধে আমাদের সুরক্ষা। সুতরাং এক আবার আমরা পরীক্ষা পাস আশা করি।

এটি বোঝায় যে আমাদের সার্বজনীন ইন্টারফেসের জন্য, সম্ভবতঃ স্থিতিশীল, আমাদের স্পষ্ট ট্র্যাকিবিলিটি প্রয়োজন যাতে আমরা দেখতে পাব যে প্রতিটি পাবলিক পদ্ধতি পরীক্ষা করা হয়েছে।

আপনার স্পষ্ট প্রশ্নের উত্তর দিতে: পাবলিক ইন্টারফেসের জন্য ইউনিট টেস্টের মান রয়েছে।

প্রতিক্রিয়া মন্তব্য সম্পাদনা:

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


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

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

2

ইউনিট পরীক্ষাগুলি বৃহত্তর পরীক্ষার কৌশলগুলির অংশ হওয়া উচিত। কোন ধরণের পরীক্ষা লিখতে হবে এবং কখন তা বেছে নেওয়ার ক্ষেত্রে আমি এই নীতিগুলি অনুসরণ করি:

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

  • জটিল যুক্তির নগেটের চারপাশে ইউনিট পরীক্ষা লেখার জন্য ড্রপ করুন। ইউনিট পরীক্ষাগুলি তাদের ওজনের পক্ষে এমন পরিস্থিতিতে যেখানে পর্যাপ্ত কোড কভারেজের জন্য লেখার জন্য শেষ-থেকে-শেষের পরীক্ষাগুলি ডিবাগ করা বা চালিত করা শক্ত হবে y

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

রব অ্যাশটনের এই বিষয়টিতে একটি সূক্ষ্ম নিবন্ধ রয়েছে, যা আমি উপরের নীতিগুলিকে স্পষ্টভাবে আঁকতে বাধ্য করেছি।


+1 - আমি অগত্যা আপনার সমস্ত পয়েন্ট (বা নিবন্ধের পয়েন্ট) এর সাথে একমত নই তবে যেখানে আমি সম্মত হই তা হল বেশিরভাগ ইউনিট পরীক্ষা অন্ধভাবে করা হলে (টিডিডি পদ্ধতির) অকেজো। তবে, আপনি যদি ইউনিট পরীক্ষা করে সময় ব্যয় করার উপযুক্ত কি তা সিদ্ধান্ত নিতে যদি আপনি স্মার্ট হন তবে সেগুলি অত্যন্ত মূল্যবান। আমি সম্পূর্ণরূপে সম্মত হই যে আপনি উচ্চ স্তরের পরীক্ষাগুলি লেখার ক্ষেত্রে বিশেষত সাবসিস্টেম স্তরের স্বয়ংক্রিয় পরীক্ষায় এখন পর্যন্ত অনেক বেশি পরিমাণে ঝাঁকুনি পান। শেষ থেকে শেষ স্বয়ংক্রিয় পরীক্ষাগুলিগুলির সাথে সমস্যাটি হ'ল কোনও সিস্টেমে যদি তার আকার / জটিলতা থাকে তবে এগুলি শক্ত, পুরোপুরি অবৈজ্ঞানিক না হলেও would
ডাঙ্ক

0

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

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

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