সাধারণত কোডিং স্ট্যান্ডার্ড সম্পর্কে কথা বলার সময় আমরা প্রোগ্রামের কোডটি নিজেই উল্লেখ করি তবে ইউনিট পরীক্ষাগুলির কী হবে? ইউনিট পরীক্ষার জন্য স্বতন্ত্র কিছু কোডিং মানদণ্ড রয়েছে? তারা কি?
সাধারণত কোডিং স্ট্যান্ডার্ড সম্পর্কে কথা বলার সময় আমরা প্রোগ্রামের কোডটি নিজেই উল্লেখ করি তবে ইউনিট পরীক্ষাগুলির কী হবে? ইউনিট পরীক্ষার জন্য স্বতন্ত্র কিছু কোডিং মানদণ্ড রয়েছে? তারা কি?
উত্তর:
আমার মাথার শীর্ষে, আমি টেস্ট কোডের জন্য কোডিং শৈলীতে তিনটি পার্থক্য ভাবতে পারি।
নামকরণের পরীক্ষার পদ্ধতিগুলিতে, আমি এর ধরণটি অনুসরণ করি shouldDoSomethingWhenSomeConditionHolds।
পরীক্ষার অভ্যন্তরে নিম্নলিখিত স্পেসিং ধরণটি অনুসরণ করা প্রথাগত:
@Test
shouldReturnAccountBalenceWhenGetBalenceIsCalled() {
// Some lines
// of setup code
// go here.
// The action being tested happens after a blank line.
// An assertion follows another blank line.
}
কেউ কেউ পরীক্ষায় একমাত্র দৃ as়তার জন্য জোর দিয়ে থাকেন তবে এটি সর্বজনীন থেকে দূরে।
ডিআরওয়াই (নিজেকে পুনরাবৃত্তি করবেন না) উত্পাদন কোডের তুলনায় পরীক্ষার কোডের বিবেচনায় কম। কিছু পুনরাবৃত্ত কোড একটি সেটআপ পদ্ধতিতে বা একটি টেস্টUtils শ্রেণিতে স্থাপন করা উচিত, পরীক্ষার কোডে শূন্য পুনরাবৃত্তির জন্য চেষ্টা করার ফলে দৃ coup়ভাবে মিলিত এবং জটিল জটিল পরীক্ষা হবে, যা রিফ্যাক্টরিংকে নিরুৎসাহিত করে।
রায় ওশেরোভ আপনার পরীক্ষার নামকরণের জন্য নিম্নলিখিত প্যাটার্নটির পরামর্শ দিয়েছেন:
NameOfMethodUnderTest_StateUnderTest_ExpectedBehavior()
Http://weblogs.asp.net/rosherove/archive/2005/04/03/ টেস্টনামিংস স্ট্যান্ডার্ডস.এসপিএক্স দেখুন
NameOfMethodUnderTestStateUnderTestExpectedBehavior();)
প্রধান জিনিসটি মনে রাখতে হবে যে ইউনিট পরীক্ষাগুলি মূলত মিনি-স্পেসিফিকেশন। এর অর্থ হ'ল জোর সবসময় পঠনযোগ্যতার উপর।
প্রথমত, এর অর্থ হ'ল নামগুলি অবশ্যই পরীক্ষার অধীনে এবং কী জোর দেওয়া হচ্ছে তা স্পষ্টভাবে যোগাযোগ করতে হবে।
দ্বিতীয়ত যদিও, যা কখনও কখনও ভুলে যায়, তা হ'ল স্পেসিফিকেশন হিসাবে তাদের ঠিক এটি করা উচিত - আচরণ নির্দিষ্টকরণ। অর্থাৎ ইউনিট পরীক্ষাগুলিতে যুক্তি থাকতে হবে না - বা সম্ভাব্যভাবে তারা প্রোগ্রামটির কার্যকারিতা পরীক্ষা করার পরিবর্তে পুনরাবৃত্তি করার ফাঁদে পড়ে।
কখনও কখনও পরীক্ষাগুলি সেট আপ করার জন্য জটিল যে বিষয়গুলিকে জড়িত করে তোলে, আপনি কোনও অবজেক্ট মা বা টেস্ট ডেটা বিল্ডারের মতো কিছু ব্যবহার করে এই সেট আপ যুক্তিকে আপনার পরীক্ষাগুলি থেকে পৃথক রাখতে চেষ্টা করতে হবে ।
আমি কয়েকটি বইয়ের সুপারিশগুলি নিয়ে আলোচনা করব:
এক্স ইউনিট পরীক্ষার প্যাটার্নস: রিফ্যাক্টরিং টেস্ট কোড: দুর্দান্ত বই, কেউ কেউ বলেছেন এটি কিছুটা শুকনো তবে আমি তা মনে করি না। বিভিন্ন পরীক্ষার আয়োজনের বিভিন্ন উপায় এবং সেগুলি কীভাবে রক্ষণাবেক্ষণযোগ্য রাখতে হয় সে সম্পর্কে প্রচুর বিবরণে যায়। প্রাসঙ্গিক যদি আপনি NUnit ইত্যাদির মতো কিছু ব্যবহার করেন
আর্ট অফ ইউনিট টেস্টিং: উদাহরণগুলিতে। নেট : পরীক্ষাগুলি রক্ষণ ও বজায় রাখার নিতান্তই সাহসের উপরে সেরা বই। সত্যই নতুন হওয়া সত্ত্বেও আমি এএএ সিনট্যাক্সটি করানোর আরও একটি উপায়ের পরিবর্তে বেশিরভাগ ইতিমধ্যে প্রহসনকারী বিভাগগুলি খুঁজে পেয়েছি।
পরীক্ষাগুলি দ্বারা পরিচালিত ক্রমবর্ধমান অবজেক্ট-ওরিয়েন্টড সফ্টওয়্যার : এই বইটি কেবল আশ্চর্যজনক! এখন পর্যন্ত সেরা ইউনিট পরীক্ষার বই এবং একমাত্র উন্নত যা ইউনিট পরীক্ষাকে ডিজাইনের প্রক্রিয়াতে প্রথম শ্রেণির নাগরিক হিসাবে রাখে। এটি যখন সর্বজনীন বিটা ছিল তখন থেকেই এটি পড়ছিল এবং সেই থেকে সুপারিশ করা হচ্ছে। পুরো বাস্তব জুড়ে ব্যবহৃত দুর্দান্ত বাস্তব-সংসার কাজের উদাহরণ। যদিও প্রথমে রায়ের বইটি পড়ার পরামর্শ দিন।
আপনার ইউনিট পরীক্ষায় যুক্তি স্থাপন করবেন না। উদাহরণস্বরূপ, ধরা যাক আপনি একটি অ্যাড পদ্ধতি পরীক্ষা করছেন, আপনার কাছে এরকম কিছু থাকতে পারে:
void MyTest_SaysHello()
{
string name = "Bob";
string expected = string.Format("Hello, {0}", name);
IMyObjectType myObject = new MyObjectType();
string actual = myObject.SayHello(name);
Assert.AreEqual(expected, actual);
}
এই বিশেষ ক্ষেত্রে, আপনি সম্ভবত পরীক্ষার মতো একই যুক্তিটির পুনরাবৃত্তি করছেন, সুতরাং আপনি "1 + 1 == 2" এর পরিবর্তে মূলত "1 + 1 == 1 + 1" পরীক্ষা করছেন, যা "আসল" পরীক্ষা। সুতরাং আপনি কীভাবে আপনার পরীক্ষার কোডটি দেখতে চান তা হ'ল:
void MyTest_SaysHello()
{
string expected = "Hello, Bob";
IMyObjectType myObject = new MyObjectType();
string actual = myObject.SayHello("Bob");
Assert.AreEqual(expected, actual);
}
দীর্ঘ, বর্ণনামূলক পদ্ধতির নাম। মনে রাখবেন, পরীক্ষার পদ্ধতিগুলি কখনই কোড থেকে কল করা হয় না (এগুলি ইউনিট টেস্ট রানার দ্বারা ডাকা হয় যা আবিষ্কার করে এবং তাদের প্রতিবিম্বের মাধ্যমে কল করে), তাই পাগল হয়ে যাওয়া এবং পদ্ধতির নাম 50-80 অক্ষর দীর্ঘ রাখা ভাল। নির্দিষ্ট নামকরণ কনভেনশন (উট-কেস, আন্ডারস্কোর, "উচিত", "অবশ্যই", "কখন", "দেওয়া", ইত্যাদি) যতক্ষণ না নামটি তিনটি প্রশ্নের উত্তর দেয় ততক্ষণ পর্যন্ত সত্যই গুরুত্বপূর্ণ নয়:
পরীক্ষা পদ্ধতি সংক্ষিপ্ত হওয়া উচিত ।
পরীক্ষার পদ্ধতিগুলির একটি সাধারণ, লিনিয়ার কাঠামো থাকা উচিত । না যদি বা লুপটি নির্মাণ করে।
পরীক্ষার পদ্ধতিগুলিতে "অ্যারেঞ্জ-অ্যাক্ট-এ্যাসেট" ধরণটি অনুসরণ করা উচিত ।
প্রতিটি পরীক্ষার একটি জিনিস পরীক্ষা করা উচিত । এর অর্থ সাধারণত প্রতি পরীক্ষায় একটি আসক্তি। মত একটি পরীক্ষা { Do A; Assert B; Assert C; }দুটি মধ্যে সংশোধন করা উচিত: { Do A; Assert B; }এবং{ Do A; Assert C; }
এলোমেলো ডেটা বা 'ডেটটাইম.নাউ' এর মতো জিনিস এড়িয়ে চলুন
নিশ্চিত হয়ে নিন যে পরীক্ষার শেষে সমস্ত পরীক্ষার সদস্যরা তাদের মূল অবস্থায় ফিরে আসবে (যেমন একটি টিয়ারডাউন ব্যবহার করে )
এমনকি আপনি যদি নিজের প্রোডাকশন কোডে নির্লিপিভাবে সদৃশতা সরিয়ে ফেলেন, পরীক্ষার ফিক্সচারগুলিতে কোড ডুপ্লিকেশন অনেক ছোট উদ্বেগ।
কিছুটা ফারমবয়ের ইতিমধ্যে যা উল্লেখ করা হয়েছে তার সাথে মিল, আমার পদ্ধতির নাম ফর্ম্যাট
<MethodName>Should<actionPerformed>When<Condition>
যেমন
GetBalanceShouldReturnAccountBalance() {