ইউনিট পরীক্ষা লেখার সময় কীভাবে পরীক্ষা করতে হয় তা আপনি কীভাবে জানবেন? [বন্ধ]


127

সি # ব্যবহার করে আমার একটি ক্লাস প্রয়োজন Userযাটির একটি ব্যবহারকারীর নাম, পাসওয়ার্ড, সক্রিয় পতাকা, প্রথম নাম, পদবি, পুরো নাম ইত্যাদি রয়েছে need

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


এই পোস্টটি বিস্তৃত প্রশ্নকে সংকীর্ণ করতে সহায়তা করবে: earnestengineer.blogspot.com/2018/03/… আপনি আপনার প্রশ্নকে কেন্দ্রীভূত করতে এই নির্দেশিকাগুলি নিতে পারেন
লিন্ডসে মুরসিলো

মনে রাখবেন পাসওয়ার্ডগুলি প্লেইন টেক্সট হিসাবে সংরক্ষণ করা উচিত নয়।
মিঃ অ্যান্ডারসন

উত্তর:


131

এ সম্পর্কে অনেক দুর্দান্ত প্রতিক্রিয়া আমার প্রশ্নেও রয়েছে : " টিডিডি শুরু - চ্যালেঞ্জস? সমাধান? সুপারিশ? "

আমি আমার ব্লগ পোস্টটি (যা আমার প্রশ্নের দ্বারা আংশিকভাবে অনুপ্রাণিত হয়েছিল) একবার দেখার পরামর্শ দিতে পারি, সে সম্পর্কে আমি কিছু ভাল প্রতিক্রিয়া পেয়েছি। যথা:

আমি জানি না কোথায় শুরু করব?

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

আপনি যা আশা করেন কেবল তার জন্য পরীক্ষা করুন

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

কেবল টেস্ট ওয়ান থিং

প্রতিটি পরীক্ষার ক্ষেত্রে কেবল একটি জিনিস পরীক্ষা করা উচিত। যদি আপনি কখনও নিজেকে পরীক্ষার মামলায় "এবং" লিখতে দেখেন তবে আপনি কিছু ভুল করছেন।

আমি আশা করি এর অর্থ আমরা "getters and setters" থেকে এগিয়ে যেতে পারি :)


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

3
যদিও কেউ কেউ এই জাতীয় জিনিসগুলির পক্ষে থাকতে পারে তবে আমি ব্যক্তিগতভাবে তা করি না। আমার মাথা ব্যাথার 90% ভালই কেবল "সবকিছু" করার চেষ্টা করে এসেছে। আমি যা বলে আশা করি তার জন্য পরীক্ষা বলি (যাতে আপনি জানেন যে আপনি সঠিক মানগুলি ফিরে পেয়ে যাচ্ছেন) তবে চেষ্টা করবেন না এবং এটিকে পুরোপুরি আবিষ্কার করবেন না। YAGNI।
রব কুপার

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

63

আপনার কোডটি পরীক্ষা করুন, ভাষা নয়।

ইউনিট পরীক্ষা যেমন:

Integer i = new Integer(7);
assert (i.instanceOf(integer));

কেবলমাত্র তখনই কার্যকর যদি আপনি একটি সংকলক লিখছেন এবং আপনার instanceofপদ্ধতিটি কাজ করছে না এমন শূন্যের সম্ভাবনা রয়েছে ।

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


1
"ফ্রেমওয়ার্কটি পরীক্ষা করবেন না" - এর জন্য উত্তম পয়েন্ট - এটির ক্ষেত্রে নতুন কিছু যখন আমি পেয়েছিলাম। +1'ed :)
রব কুপার

38

এটি আমাকে ইউনিট পরীক্ষায় ফেলেছে এবং এটি আমাকে খুব আনন্দিত করেছে

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

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

আমি কীভাবে এটির কোডিং শুরু করবেন তা জানতাম না, কারণ অনেকগুলি বিভিন্ন অর্থপ্রদানের বিকল্প ছিল। একটি চালান $ 100 হতে পারে তবে গ্রাহক কেবল $ 99 স্থানান্তরিত করতে পারেন। হতে পারে আপনি কোনও গ্রাহকের কাছে বিক্রয় চালানগুলি প্রেরণ করেছেন তবে আপনি সেই গ্রাহকের কাছ থেকেও কিনেছেন। সুতরাং আপনি তাকে 300 ডলারে বিক্রি করেছেন তবে আপনি 100 ডলারে কিনেছেন। ব্যালেন্স নিষ্পত্তি করতে আপনি আপনার গ্রাহককে 200 ডলার দেবেন বলে আশা করতে পারেন। এবং যদি আপনি 500 ডলারে বিক্রি করেন তবে গ্রাহক আপনাকে কেবল 250 ডলার দেয়?

সুতরাং অনেকগুলি সম্ভাবনা সমাধান করার জন্য আমার খুব জটিল সমস্যা হয়েছিল যে একটি দৃশ্যে নিখুঁতভাবে কাজ করবে তবে অন্য ধরণের ইনভোসি / পেমেন্ট সমন্বয়টি ভুল হবে।

এখানেই ইউনিট টেস্টিং উদ্ধারকাজে এসেছিল।

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

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

পরীক্ষাটি চালানোর পরে আমি ডাটাবেসে গিয়ে ডাবল চেক করতাম যে আমি কী প্রত্যাশা রেখেছিলাম তা সেখানে ছিল কিনা।

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

আমি প্রথম পরীক্ষাটি চালিয়েছি, আমার পরীক্ষা পাস না হওয়া অবধি একটি ছোট বাগ ঠিক করেছি।

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

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

তারপরে আমি আরও জটিল পরিস্থিতিতে যাওয়ার পথে কাজ করেছি।

1) একটি নতুন দৃশ্যের কথা চিন্তা করুন

2) সেই দৃশ্যের জন্য একটি পরীক্ষা লিখুন

3) এটি পাস হবে কিনা তা দেখতে সেই একক পরীক্ষা চালান

৪) যদি আমি কোডটি ডিবাগ এবং সংশোধন না করি যতক্ষণ না এটি পাস হয়।

5) কোডটি সংশোধন করার সময় আমি সমস্ত পরীক্ষা চালিয়ে যাচ্ছি

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

আমি নিশ্চিত যে ইউনিট পরীক্ষার সাহায্যে আমাকে কোডিংয়ের কয়েক দিন (বা সপ্তাহ) বাঁচানো হয়েছিল এবং আমার পদ্ধতির যথাযথতার গ্যারান্টি দিচ্ছে।

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

হ্যাঁ, এমনকি যদি কোনও ব্যবহারকারী এমন কিছু করেন যা আপনি ভাবেননি বা তাকে কাজ করতে বাধা দিয়েছেন তবে পরীক্ষিত কোডটিতেও বাগ থাকতে পারে

আমার অর্থ প্রদানের পদ্ধতিটি পরীক্ষা করার জন্য আমি নীচে কয়েকটি পরীক্ষার তৈরি করেছি।

public class TestPayments
{
    InvoiceDiaryHeader invoiceHeader = null;
    InvoiceDiaryDetail invoiceDetail = null;
    BankCashDiaryHeader bankHeader = null;
    BankCashDiaryDetail bankDetail = null;



    public InvoiceDiaryHeader CreateSales(string amountIncVat, bool sales, int invoiceNumber, string date)
    {
        ......
        ......
    }

    public BankCashDiaryHeader CreateMultiplePayments(IList<InvoiceDiaryHeader> invoices, int headerNumber, decimal amount, decimal discount)
    {
       ......
       ......
       ......
    }


    [TestMethod]
    public void TestSingleSalesPaymentNoDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 1, "01-09-2008"));
        bankHeader = CreateMultiplePayments(list, 1, 119.00M, 0);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(1, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(119M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(0M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
    }

    [TestMethod]
    public void TestSingleSalesPaymentDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 2, "01-09-2008"));
        bankHeader = CreateMultiplePayments(list, 2, 118.00M, 1M);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(1, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(118M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(1M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
    }

    [TestMethod]
    [ExpectedException(typeof(ApplicationException))]
    public void TestDuplicateInvoiceNumber()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("100", true, 2, "01-09-2008"));
        list.Add(CreateSales("200", true, 2, "01-09-2008"));

        bankHeader = CreateMultiplePayments(list, 3, 300, 0);
        bankHeader.Save();
        Assert.Fail("expected an ApplicationException");
    }

    [TestMethod]
    public void TestMultipleSalesPaymentWithPaymentDiscount()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("119", true, 11, "01-09-2008"));
        list.Add(CreateSales("400", true, 12, "02-09-2008"));
        list.Add(CreateSales("600", true, 13, "03-09-2008"));
        list.Add(CreateSales("25,40", true, 14, "04-09-2008"));

        bankHeader = CreateMultiplePayments(list, 5, 1144.00M, 0.40M);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(4, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(118.60M, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(400, bankHeader.BankCashDetails[0].Payments[1].PaymentAmount);
        Assert.AreEqual(600, bankHeader.BankCashDetails[0].Payments[2].PaymentAmount);
        Assert.AreEqual(25.40M, bankHeader.BankCashDetails[0].Payments[3].PaymentAmount);

        Assert.AreEqual(0.40M, bankHeader.BankCashDetails[0].Payments[0].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[2].PaymentDiscount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].PaymentDiscount);

        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[2].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].InvoiceHeader.Balance);
    }

    [TestMethod]
    public void TestSettlement()
    {
        IList<InvoiceDiaryHeader> list = new List<InvoiceDiaryHeader>();
        list.Add(CreateSales("300", true, 43, "01-09-2008")); //Sales
        list.Add(CreateSales("100", false, 6453, "02-09-2008")); //Purchase

        bankHeader = CreateMultiplePayments(list, 22, 200, 0);
        bankHeader.Save();

        Assert.AreEqual(1, bankHeader.BankCashDetails.Count);
        Assert.AreEqual(2, bankHeader.BankCashDetails[0].Payments.Count);
        Assert.AreEqual(300, bankHeader.BankCashDetails[0].Payments[0].PaymentAmount);
        Assert.AreEqual(-100, bankHeader.BankCashDetails[0].Payments[1].PaymentAmount);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[0].InvoiceHeader.Balance);
        Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[1].InvoiceHeader.Balance);
    }

1
আপনার ইউনিট পরীক্ষায় একটি বাগ খুঁজে পেয়েছে! আপনি এর মধ্যে একটিতে 2 টি যুক্ত করার পরিবর্তে এই লাইনটি পুনরাবৃত্তি করুন:Assert.AreEqual(0, bankHeader.BankCashDetails[0].Payments[3].InvoiceHeader.Balance);
রায়ান পেশেল

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

2
আপনি পরীক্ষায় প্রতি একাধিক আসরের বিধিও ভেঙে ফেলেছেন।
স্টিভ

13

যদি তারা সত্যিই তুচ্ছ হয়, তবে পরীক্ষার বিরক্ত করবেন না। উদাহরণস্বরূপ, যদি সেগুলি এভাবে প্রয়োগ করা হয়;

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }
}

অন্যদিকে, আপনি যদি কিছু চালাক করে চলেছেন (যেমন গেটার / সেটারে পাসওয়ার্ডটি এনক্রিপ্ট করা এবং ডিক্রিপ্ট করা) তবে এটি পরীক্ষা দিন।


10

নিয়মটি হ'ল আপনার লেখার প্রতিটি যুক্তি পরীক্ষা করতে হবে। আপনি যদি গেটার এবং সেটটারগুলিতে কিছু নির্দিষ্ট কার্যকারিতা প্রয়োগ করেন তবে আমি মনে করি সেগুলি পরীক্ষার উপযুক্ত। যদি তারা কেবল কয়েকটি ব্যক্তিগত ক্ষেত্রে মান নির্ধারণ করে তবে বিরক্ত করবেন না।


6

কোনটি পদ্ধতি পরীক্ষা করা হয় এবং কোনটি হয় না সে সম্পর্কে কেউ কোথায় রেখা আঁকবে এই প্রশ্নটি মনে হচ্ছে seems

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

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

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

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

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

এবং ইউনিট পরীক্ষাগুলির সাথে আপনি তুচ্ছ পদ্ধতিতে মোড়ক ফেলেছিলেন এমনটি জুনিয়র দলের সাথী যখন তুচ্ছ পদ্ধতিতে অ-তুচ্ছ পদ্ধতিতে পরিবর্তন করতে এবং পরীক্ষার আপডেট করার জন্য অনুরোধ করেছিলেন তখন তারা দেখতে পাবে এবং এখন কেউই সমস্যায় নেই কারণ ত্রুটিটি ছিল উত্পাদন পৌঁছনো থেকে।

যেভাবে আমরা কোড করি, এবং যে কোডটি আমাদের কোড থেকে দেখা যায়, তা অন্যকে সহায়তা করতে পারে।


4

আর একটি ক্যানোনিকাল উত্তর। এটি, আমি বিশ্বাস করি, রন জেফরিসের কাছ থেকে:

আপনি যে কোডটি কাজ করতে চান তা কেবলমাত্র পরীক্ষা করুন।


3

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

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


3

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

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


আপনি KISS নীতির একটি ভাল পয়েন্ট তৈরি করেছেন খুশি .. আমার প্রায়শই এমন পরীক্ষাগুলি থাকে যা আক্ষরিক অর্থে কোডের 2-3 লাইনের মতো, বাস্তব ছোট, সাধারণ পরীক্ষার। Grok করা সহজ এবং বিরতি হার্ড :) + + 1'ed
রব কুপার

3

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

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


3

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


2

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


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

2
তাঁর বক্তব্যটি পরবর্তীতে তাদের সাথে যুক্তি যুক্ত হতে পারে।
কিংবদন্তি লেন্থথ

2

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

উত্তরাধিকারের শ্রেণিবিন্যাসে, এলএসপিতে সম্মতি পরীক্ষা করার জন্য নিশ্চিত হন ।

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


2

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


2

ক্যানোনিকাল উত্তর হ'ল "সম্ভবত যে কোনও কিছু ভেঙে দিতে পারে এমন কোনও কিছুর পরীক্ষা করুন।" আপনি যদি নিশ্চিত হন যে সম্পত্তিগুলি ভাঙবে না, তবে সেগুলি পরীক্ষা করবেন না।

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


1

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


1

যদি প্রমাণীকরণ এবং সংরক্ষণের পদ্ধতিগুলি বৈশিষ্ট্যগুলি ব্যবহার করে, তবে আপনার পরীক্ষাগুলি পরোক্ষভাবে বৈশিষ্ট্যগুলিকে স্পর্শ করবে। যতক্ষণ সম্পত্তিগুলি কেবল ডেটাতে অ্যাক্সেস সরবরাহ করে, ততক্ষণ স্পষ্ট পরীক্ষার প্রয়োজন হবে না (যদি না আপনি 100% কভারেজ না যান)।


1

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


1

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

ব্যক্তিগতভাবে আমি মোককে মক অবজেক্ট ফ্রেমওয়ার্ক হিসাবে ব্যবহার করি এবং তারপরে যাচাই করে দেখি যে আমার অবজেক্টটি আশেপাশের অবজেক্টগুলিকে যেমনভাবে কল করে তাই কল করে।


1

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

সাধারণ পূর্ণসংখ্যার ক্ষেত্রেও এটি প্রযোজ্য - আপনি পূর্ণসংখ্যার পরিবর্তে দীর্ঘ সময় পার করলে কী হবে? আপনি ইউটি লেখার জন্য এটিই কারণ:


1

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


1

যতদূর সম্ভব ইউনিট পরীক্ষা করে আপনার "কোডের প্রতিটি অ-তুচ্ছ ব্লক" পরীক্ষা করা উচিত।

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

আপনার প্রমাণীকরণ () এবং সংরক্ষণ () পদ্ধতিগুলি পরীক্ষার জন্য ভাল প্রার্থীদের মতো দেখায়।


1

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

পরীক্ষাগুলি লিখার পরে অনেক বেশি বেদনাদায়ক, তবে সম্ভব।

আপনার অবস্থানটিতে আমি যা করব তা এখানে:

  1. মূল ফাংশনটি পরীক্ষা করে এমন পরীক্ষার একটি বেসিক সেট লিখুন।
  2. এনসিওভার পান এবং এটি আপনার পরীক্ষায় চালান। আপনার পরীক্ষার কভারেজ সম্ভবত এই সময়ে প্রায় 50% হবে।
  3. আপনি প্রায় 80% -90% এর কভারেজ না পাওয়া পর্যন্ত আপনার প্রান্তের কেসগুলিকে কভার করে এমন পরীক্ষা যোগ করুন

এটি আপনাকে ইউনিট পরীক্ষাগুলির একটি দুর্দান্ত ওয়ার্কিং সেট দেয় যা নিগ্রহের বিরুদ্ধে ভাল বাফার হিসাবে কাজ করবে।

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

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


1

স্পষ্টতই কাজ করছে (বয়লারপ্লেট) কোড পরীক্ষা করবেন না। সুতরাং যদি আপনার সেটার এবং গেটারগুলি কেবল "সম্পত্তি মূল্য = মান" এবং "রিটার্ন প্রপার্টিভ্যালু" হয় তবে এটি পরীক্ষা করার কোনও মানে হয় না।


1

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

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

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

হ্যাঁ, আপনাকে বৈশিষ্ট্যগুলি পরীক্ষা করার বিষয়ে চিন্তা করার দরকার নেই।


1

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


1

আপনি জিইউআই ইন্টারফেসের বাইরে পরীক্ষাযোগ্য এটির জন্য কোড লিখছেন এমন কোনও কিছুর জন্য আমি একটি পরীক্ষা লিখব।

সাধারণত, আমি যে যুক্তিটি লিখি তাতে যে কোনও যুক্তি যুক্ত থাকে সেটিকে আমি অন্য স্তরের বা ব্যবসায়িক যুক্তির স্তরের ভিতরে রাখি।

তারপরে যা কিছু করে সেগুলির জন্য টেস্ট লেখার কাজটি করা সহজ।

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

আমার যদি এর মতো ক্লাস থাকে:

   public class AccountService
    {
        public void DebitAccount(int accountNumber, double amount)
        {

        }

        public void CreditAccount(int accountNumber, double amount)
        {

        }

        public void CloseAccount(int accountNumber)
        {

        }
    }

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

   [TestFixture]
    public class AccountServiceTests
    {
        [Test]
        public void DebitAccountTest()
        {

        }

        [Test]
        public void CreditAccountTest()
        {

        }

        [Test]
        public void CloseAccountTest()
        {

        }
    }

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

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

সুতরাং, গল্পটির নৈতিকতা হ'ল, এমন কোনও কিছু পরীক্ষা করুন যা আপনার সম্পর্কে উদ্বিগ্ন হতে পারে এমন কিছু করে, ইউনিট পরীক্ষা করে নির্দিষ্ট আকারের যা ছোট আকারের তা পরীক্ষা করে রাখে, প্রচুর পরীক্ষা ভাল।

আপনার ব্যবসায়ের যুক্তিটিকে ইউজার ইন্টারফেস স্তরের বাইরে রাখুন যাতে আপনি সহজেই তাদের জন্য পরীক্ষা লিখতে পারেন এবং আপনি ভাল হবেন।

উভয়ই ভিজ্যুয়াল স্টুডিওতে সহজেই সংহত করার জন্য আমি টেস্টড্রাইভন. নেট বা রিশার্পারকে সুপারিশ করি ।


1

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

অন্যরা যেমন বলেছে, গেটার্স এবং সেটারগুলির ইউনিট টেস্টগুলি ওভারকিল করা হয়, যদি না আপনার গেটর এবং সেটারগুলিতে শর্তযুক্ত লজিক থাকে।


1

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

প্রচুর পরীক্ষাগুলি সহ কোড তবে একটি ছোট কভারেজ ভালভাবে পরীক্ষা করা যায় নি। এটি বলেছিল যে, 100% কভারেজ সহ কোড কিন্তু সীমানা এবং ত্রুটির ক্ষেত্রে পরীক্ষা না করাও দুর্দান্ত নয়।

আপনি উচ্চ কভারেজ (90% সর্বনিম্ন) এবং ভেরিয়েবল ইনপুট ডেটার মধ্যে ভারসাম্য চান।

"আবর্জনা" এর জন্য পরীক্ষা করতে ভুলবেন না!

এছাড়াও, ইউনিট-পরীক্ষা কোনও ইউনিট-পরীক্ষা নয় যদি না এটি ব্যর্থতার জন্য পরীক্ষা না করে। ইউনিট-পরীক্ষাগুলি যা দৃser়ভাবে জানে না বা পরিচিত ব্যতিক্রমগুলি চিহ্নিত রয়েছে কেবল তা পরীক্ষা করবে যে রান করার সময় কোডটি মারা যায় না!

আপনার পরীক্ষাগুলি ডিজাইন করা দরকার যাতে তারা সর্বদা ব্যর্থতা বা অপ্রত্যাশিত / অযাচিত ডেটা রিপোর্ট করে!


1

এটি আমাদের কোডকে আরও উন্নত করে ... পিরিয়ড!

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

ইউনিট পরীক্ষার জন্য সত্য আত্মায়, এই পরীক্ষাগুলি প্রাথমিকভাবে আমাদের কোডের আরও "পরীক্ষা" করার জন্য থাকে না ; বা 90% -100% ভাল কোড কভারেজ পেতে to এগুলি প্রথমে পরীক্ষাগুলি লেখার হ'ল সুবিধা । বড় বেতনটি টিডিডির প্রাকৃতিক প্রক্রিয়ার কারণে আমাদের প্রডাকশন কোডটি আরও ভাল লেখা হবে written

এই ধারণাটি আরও ভালভাবে জানানোর জন্য, নিম্নলিখিতটি পড়তে সহায়ক হতে পারে:

ইউনিট টেস্টগুলির ত্রুটিযুক্ত তত্ত্বের
উদ্দেশ্যগত সফ্টওয়্যার বিকাশ

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


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

আমি ভুল করে এসেছি। আমি বোঝাতে চাইনি যে উত্পাদন কোডের পরে ইউনিট পরীক্ষাগুলির মান থাকে না। তবে তাদের মান কমে যায়। ইউনিট পরীক্ষার সর্বাধিক সুবিধা হ'ল অন্তর্নিহিত যাদু থেকে আসে যখন আমরা তাদের আমাদের উত্পাদন বিকাশ করতে দেই occurs
স্কট সাদ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.