কোনও গল্পকে একটি ভাল ধারণা বলতে ইউনিট টেস্টগুলি ব্যবহার করা হচ্ছে?

Question

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

• RequiresLogin_should_redirect_when_not_logged_in
• RequiresLogin_should_pass_through_when_logged_in
• Login_should_work_when_given_proper_credentials

ব্যক্তিগতভাবে, আমি এটি "যথাযথ" বলে মনে হলেও এটি কিছুটা কুৎসিত বলে মনে করি। আমি কেবল সেগুলি স্ক্যান করে পরীক্ষার মধ্যে পার্থক্য করতেও সমস্যা করি (কেবলমাত্র কী ব্যর্থ হয়েছে তা জানতে আমাকে প্রথমে পদ্ধতির নামটি পড়তে হবে)

সুতরাং, আমি ভেবেছিলাম যে সম্ভবত পরীক্ষাগুলি যা খাঁটি কার্যকারিতা পরীক্ষা করে সেগুলি লেখার পরিবর্তে, সম্ভবত এমন পরিস্থিতিতে এমন কিছু পরীক্ষার সংকলন লিখুন যা দৃশ্যাবলীর অন্তর্ভুক্ত।

উদাহরণস্বরূপ, এটি একটি পরীক্ষার স্টাব যার সাথে আমি এলাম:

public class Authentication_Bill
{
    public void Bill_has_no_account() 
    { //assert username "bill" not in UserStore
    }
    public void Bill_attempts_to_post_comment_but_is_redirected_to_login()
    { //Calls RequiredLogin and should redirect to login page
    }
    public void Bill_creates_account()
    { //pretend the login page doubled as registration and he made an account. Add the account here
    }
    public void Bill_logs_in_with_new_account()
    { //Login("bill", "password"). Assert not redirected to login page
    }
    public void Bill_can_now_post_comment()
    { //Calls RequiredLogin, but should not kill request or redirect to login page
    }
}

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

যাইহোক, এটি কি আদৌ পরামর্শমূলক প্যাটার্ন? অথবা, এটি "ইউনিট" পরীক্ষার পরিবর্তে আমার API এর ইন্টিগ্রেশন পরীক্ষার জন্য একটি উপযুক্ত ফিট হতে পারে? এটি কেবলমাত্র একটি ব্যক্তিগত প্রকল্পে, তাই আমি পরীক্ষাগুলির জন্য উন্মুক্ত যা ভাল যেতে পারে বা নাও পারে।

Comments

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

— ইয়ানিস

আমি মনে করি এটি স্বাদের বিষয়। ব্যক্তিগতভাবে আমি _testসংযুক্তি দিয়ে যা যা পরীক্ষা করি তার নাম ব্যবহার করি এবং আমি কী ফলাফল আশা করি তা নোট করতে মন্তব্যগুলি ব্যবহার করি। যদি এটি কোনও ব্যক্তিগত প্রকল্প হয় তবে এমন কিছু স্টাইল সন্ধান করুন যার সাথে আপনি স্বাচ্ছন্দ্য বোধ করেন এবং তাতে আঁকুন।

— মিস্টার লিস্টার

আমি অ্যারেঞ্জ / অ্যাক্ট / এ্যাসেট প্যাটার্ন ব্যবহার করে ইউনিট টেস্ট লেখার আরও প্রচলিত পদ্ধতিতে বিশদ সহ উত্তর লিখেছি, তবে একজন বন্ধু github.com/cucumber/cucumber/wiki/Gherkin ব্যবহার করে অনেক সাফল্য পেয়েছে , যা চশমা এবং আফিকের জন্য ব্যবহৃত শসা পরীক্ষা করতে পারে।

— স্টুপারউজার

আপনি নুনিট বা অনুরূপের সাথে যে পদ্ধতিটি দেখিয়েছেন আমি তা ব্যবহার করব না, যদিও এনএসপেক আরও বেশি গল্প চালিত প্রকৃতিতে প্রসঙ্গ তৈরি এবং পরীক্ষার জন্য সমর্থন করেছে: nspec.org

— মাইক

"বিল" কে "ব্যবহারকারী" এ পরিবর্তন করুন এবং আপনার কাজ শেষ হয়েছে

— স্টিভেন এ। লো

Answer 1

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

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

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

সম্পাদনা: অবশ্যই এটি আপনার পরীক্ষার "গল্প" প্রকৃতির বিরুদ্ধ বলে মনে হচ্ছে তবে আপনি যদি আপনার সহায়ক পদ্ধতিগুলি অর্থপূর্ণ নাম দেন তবে আপনি প্রতিটি পরীক্ষার মধ্যেই আপনার গল্পগুলি খুঁজে পান।

সুতরাং, এটি দেখতে এইরকম হওয়া উচিত:

[TestFixture]
public class Authentication_Bill
{
    [Setup]
    public void Init()
    {  // bring the system in a predefined state, with noone logged in so far
    }

    [Test]
    public void Test_if_Bill_can_create_account()
    {
         CreateAccountForBill();
         // assert that the account was created properly 
    }

    [Test]
    public void Test_if_Bill_can_post_comment_after_login()
    { 
         // here is the "story" now
         CreateAccountForBill();
         LoginWithBillsAccount();
         AddCommentForBill();
        //  assert that the right things happened
    }

    private void CreateAccountForBill()
    {
        // ...
    }
    // ...
}

Comments

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

— বিডিএসএল

Answer 2

ইউনিট পরীক্ষাগুলির সাথে গল্প বলার ক্ষেত্রে একটি সমস্যাটি হ'ল এটি স্পষ্ট করে না যে ইউনিট পরীক্ষাগুলি একে অপরের থেকে সম্পূর্ণ স্বাধীনভাবে সাজানো উচিত।

একটি ভাল ইউনিট পরীক্ষা অন্য সমস্ত নির্ভরশীল কোড থেকে সম্পূর্ণ বিচ্ছিন্ন করা উচিত, এটি কোডের ক্ষুদ্রতম ইউনিট যা পরীক্ষা করা যেতে পারে।

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

আরও গভীরতার একটি ভাল নিবন্ধটি নোংরা হাইব্রিড পরীক্ষার সর্বোত্তম ।

ক্লাস, পদ্ধতি এবং ফলাফলগুলি পাঠযোগ্য ও গ্রেট আর্ট অফ ইউনিট পরীক্ষার নামকরণ কনভেনশন ব্যবহার করে make

পরীক্ষা ক্লাস:

ClassUnderTestTests

পরীক্ষণ পদ্ধতি:

MethodUnderTest_Condition_ExpectedResult

@ ডক ব্রাউন এর উদাহরণটি অনুলিপি করতে, [সেটআপ] যা প্রতিটি পরীক্ষার আগে চলে তা ব্যবহার না করে, আমি পরীক্ষার জন্য বিচ্ছিন্ন বস্তু তৈরির সহায়ক পদ্ধতি লিখি।

[TestFixture]
public class AuthenticationTests
{
    private Authentication GetAuthenticationUnderTest()
    {
        // create an isolated Authentication object ready for test
    }

    [Test]
    public void CreateAccount_WithValidCredentials_CreatesAccount()
    {
         //Arrange
         Authentication codeUnderTest = GetAuthenticationUnderTest();
         //Act
         Account result = codeUnderTest.CreateAccount("some", "valid", "data");
         //Assert
         //some assert
    }

    [Test]
    public void CreateAccount_WithInvalidCredentials_ThrowsException()
    {
         //Arrange
         Authentication codeUnderTest = GetAuthenticationUnderTest();
         Exception result;
         //Act
         try
         {
             codeUnderTest.CreateAccount("some", "invalid", "data");
         }
         catch(Exception e)
         {
             result = e;
         }
         //Assert
         //some assert
    }
}

সুতরাং ব্যর্থ পরীক্ষাগুলির একটি অর্থপূর্ণ নাম রয়েছে যা আপনাকে সঠিকভাবে কী পদ্ধতিতে ব্যর্থ হয়েছে, শর্ত এবং প্রত্যাশিত ফলাফল সম্পর্কে কিছু বিবরণ দেয়।

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

Comments

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

— ডক ব্রাউন

Answer 3

আপনি যা বর্ণনা করছেন তা আমার কাছে ইউনিট পরীক্ষার চেয়ে আরও বেশি বেহেভিয়ার ড্রাইভন ডিজাইন (বিডিডি) এর মতো । কটাক্ষপাত SpecFlow যা .NET BDD কারিগরি উপর ভিত্তি হয় ক্ষীরা ডিএসএল।

শক্তিশালী স্টাফ যা কোনও মানুষ কোডিং সম্পর্কে কিছু না জেনে পড়তে / লিখতে পারে। আমাদের পরীক্ষার দলটি আমাদের ইন্টিগ্রেশন টেস্ট স্যুটগুলির জন্য এটির উন্নতি করতে দুর্দান্ত সাফল্য উপভোগ করছে।

ইউনিট পরীক্ষার জন্য সম্মেলনগুলি সম্পর্কে, @ ডকব্রাউনের উত্তরটি শক্ত মনে হচ্ছে।

Comments

তথ্যের জন্য, বিডিডি হুবহু টিডিডির মতো, এটি কেবল লেখার স্টাইলে পরিবর্তিত হয়। উদাহরণ: টিডিডি = assert(value === expected)বিডিডি = value.should.equals(expected)+ আপনি স্তরগুলির বৈশিষ্ট্যগুলি বর্ণনা করেন যা "ইউনিট পরীক্ষার স্বাধীনতা" সমস্যার সমাধান করে। এটি দুর্দান্ত স্টাইল!

— অফিরমো