একক ইউনিট পরীক্ষায় একাধিক সংস্থান থাকা কি ঠিক হবে?

Question

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

নিম্নলিখিত প্রকল্পের হোম পৃষ্ঠায় লিখিত আছে:

যথাযথ ইউনিট পরীক্ষাগুলি ঠিক এক কারণে ব্যর্থ হওয়া উচিত, এজন্য আপনাকে প্রতি ইউনিট পরীক্ষায় একটি প্রতিস্থাপন ব্যবহার করা উচিত।

এবং, রায়, মন্তব্যগুলিতে লিখেছেন:

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

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

Comments

একাধিক বক্তব্য না রেখে আপনি কীভাবে উপহাস করবেন? মকটির প্রতিটি প্রত্যাশা আপনার নিজের উপর চাপানো কলগুলির যে কোনও অর্ডার সহ নিজের মধ্যে একটি দৃser়তা।

— ক্রিস্টোফার ক্রিউটজিগ

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

— ট্র্যাভিস পার্কগুলি

আমি মনে করি থাম্বের একটি সাধারণ নিয়ম হিসাবে আপনার পরীক্ষার প্রতি সংখ্যার সংখ্যা কমিয়ে আনার চেষ্টা করা উচিত। যাইহোক, যতক্ষণ না পরীক্ষাটি কোডের নির্দিষ্ট স্থানে সমস্যাটি যথেষ্ট পরিমাণে সঙ্কুচিত করে, ততক্ষণে এটি একটি দরকারী পরীক্ষা।

— কন্ডিশন

আমি এমন কেসগুলি দেখেছি যেখানে বিভিন্ন প্রান্ত-কেস আচরণের পরীক্ষা করার জন্য RowTest(এমবিউনিট) / TestCase(এনউনিট) এর পরিবর্তে একাধিক সংস্থান ব্যবহার করা হয়েছিল। কাজের জন্য উপযুক্ত সরঞ্জামগুলি ব্যবহার করুন! (দুর্ভাগ্যক্রমে, এমএসটিস্টের এখনও সারি-পরীক্ষার সক্ষমতা আছে বলে মনে হয় না))

— গ্যালাকটিক

@ গ্যালাকটিক কাউবয় আপনি পরীক্ষার ডেটা উত্সগুলির অনুরূপ কার্যকারিতা RowTestএবং TestCaseব্যবহার করতে পারেন । আমি দুর্দান্ত সাফল্যের সাথে একটি সাধারণ সিএসভি ফাইল ব্যবহার করছি।

— জুলাইলেগন

Answer 1

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

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

আপনি একাধিক সংস্থান কীভাবে সমাধান করবেন?

Comments

এই উত্তরটি পছন্দ করুন - যেমন এটি ঠিক আছে, তবে এটি সাধারণ পরিস্থিতিতে ভাল নয় (-:

— মার্ফ

Ehh? তুমি ওটা কেন করবে? পদ্ধতিটির বাস্তবায়ন কি ঠিক একই?

— jgauffin

প্রতি ইউনিট পরীক্ষায় একক দৃsert় হ'ল পাঠককে উপরে ও নীচে স্ক্রোল করার দক্ষতা পরীক্ষা করার এক দুর্দান্ত উপায়।

— টম

এর পিছনে কোন যুক্তি? যেমনটি, এই বর্তমান উত্তরটি ঠিক কী হওয়া উচিত তা জানিয়েছে, তবে কেন তা নয়।

— স্টিভেন জিউরিস

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

— পিটার

Answer 2

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

মূলটি হ'ল আপনার কেবলমাত্র একটি ক্রিয়া রয়েছে এবং তারপরে আপনি দৃ action়তা ব্যবহার করে সেই ক্রিয়াটির ফলাফলগুলি পরিদর্শন করেন। তবে এটি "ব্যবস্থা করুন, আইন, দৃsert়তা, পরীক্ষার সমাপ্তি "। আপনি যদি আরও একটি ক্রিয়া করে পরীক্ষা চালিয়ে যাওয়ার প্রলোভন দেখান এবং এরপরে আরও দৃser় প্রতিবেদন করে থাকেন তবে পরিবর্তে এটিকে একটি আলাদা পরীক্ষা করুন।

আমি একাধিক দৃ testing় বক্তব্যগুলি দেখতে পেরে খুশি যে একই ক্রিয়াটির পরীক্ষার অংশগুলি। যেমন

[Test]
public void ValueIsInRange()
{
  int value = GetValueToTest();

  Assert.That(value, Is.GreaterThan(10), "value is too small");
  Assert.That(value, Is.LessThan(100), "value is too large");
} 

অথবা

[Test]
public void ListContainsOneValue()
{
  var list = GetListOf(1);

  Assert.That(list, Is.Not.Null, "List is null");
  Assert.That(list.Count, Is.EqualTo(1), "Should have one item in list");
  Assert.That(list[0], Is.Not.Null, "Item is null");
} 

এগুলি আপনি একটি দৃ as়তার সাথে একত্রিত করতে পারেন তবে এটি করা বা করা উচিত বলে জোর দেওয়া থেকে আলাদা কথা । তাদের একত্রিত করে কোনও উন্নতি হয় না।

যেমন প্রথমটি হতে পারে

Assert.IsTrue((10 < value) && (value < 100), "Value out of range"); 

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

নোট : আমি এখানে যে কোডটি লিখছি তা হ'ল নুনিট সহ সি #, তবে নীতিগুলি অন্য ভাষা এবং ফ্রেমওয়ার্ক সহ ধারণ করবে। বাক্য গঠনটিও একইরকম হতে পারে।

Comments

মূলটি হ'ল আপনার কেবলমাত্র একটি ক্রিয়া রয়েছে এবং তারপরে আপনি দৃ action়তা ব্যবহার করে সেই ক্রিয়াটির ফলাফলগুলি পরিদর্শন করেন।

— অমিতাভ

আমি মনে করি এটি আকর্ষণীয়ও বটে, যদি অ্যারেঞ্জ করা ব্যয়বহুল হয় তবে এক হিসাবে আরও অধিক পরিমাণে অবস্থান করা উচিত।

— রিক্সিনো

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

— শান লুটিন

সুতরাং আমি যদি জ্যাকো উত্তরের সাথে তুলনা করি তবে "কেবলমাত্র একটি দৃ as়পদ" "আমার পক্ষে কেবলমাত্র একটি গ্রুপের দাবী" হয়ে যায় যা আমার কাছে আরও বেশি অর্থবোধ করে।

— ওয়ালফ্র্যাট

এটি একটি ভাল উত্তর, তবে আমি একমত যে একটি একক দৃ better়তর ভাল হয় না। খারাপ দৃsert় উদাহরণটি আরও ভাল নয়, তবে এর অর্থ এই নয় যে সঠিকভাবে করা হলে একটি একক দাবী আরও ভাল হবে না। অনেক লাইব্রেরি কাস্টম জমিদারি / ম্যাচারদের মঞ্জুরি দেয় যাতে ইতিমধ্যে উপস্থিত না থাকলে কিছু তৈরি করা যায়। উদাহরণ হিসেবে বলা যায় Assert.IsBetween(10, 100, value)যে ছাপে Expected 8 to be between 10 and 100 হয় বেশী ভালো দুটি পৃথক আমার মতে দাবি। আপনি অবশ্যই যুক্তি দিতে পারেন যে এটি প্রয়োজনীয় নয়, তবে এটির পুরো সেট তৈরির আগে কোনও একক প্রতিরোধকে হ্রাস করা সহজ কিনা তা সাধারণত বিবেচনা করা উচিত।

— Thor84no

Answer 3

আমি কখনও ভাবিনি যে একের বেশি দাবি করা খারাপ জিনিস।

আমি সব সময় এটা:

public void ToPredicateTest()
{
    ResultField rf = new ResultField(ResultFieldType.Measurement, "name", 100);
    Predicate<ResultField> p = (new ConditionBuilder()).LessThanConst(400)
                                                       .Or()
                                                       .OpenParenthesis()
                                                       .GreaterThanConst(500)
                                                       .And()
                                                       .LessThanConst(1000)
                                                       .And().Not()
                                                       .EqualsConst(666)
                                                       .CloseParenthesis()
                                                       .ToPredicate();
    Assert.IsTrue(p(ResultField.FillResult(rf, 399)));
    Assert.IsTrue(p(ResultField.FillResult(rf, 567)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 400)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 666)));
    Assert.IsFalse(p(ResultField.FillResult(rf, 1001)));

    Predicate<ResultField> p2 = (new ConditionBuilder()).EqualsConst(true).ToPredicate();

    Assert.IsTrue(p2(new ResultField(ResultFieldType.Confirmation, "Is True", true)));
    Assert.IsFalse(p2(new ResultField(ResultFieldType.Confirmation, "Is False", false)));
}

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

আমি কেবল একটি ইউনিট ( ToPredicateপদ্ধতি) পরীক্ষা করছি , তবে আমি পরীক্ষায় যা ভাবতে পারি তার সবই আমি আবরণ করছি।

Comments

ত্রুটি সনাক্তকরণের কারণে একাধিক আসক্তিগুলি খারাপ। আপনি যদি আপনার প্রথম অ্যাসেটরটি ব্যর্থ করে থাকেন sআইএসআর্টু, অন্য দাবিগুলি কার্যকর করা হবে না এবং আপনি তাদের কাছ থেকে কোনও তথ্য পাবেন না। অন্যদিকে আপনার যদি 5 টির পরিবর্তে 1 টির পরিবর্তে 5 টি পরীক্ষা থাকে তবে আপনি কিছু উপকারজনক কিছু পেতে পারেন

— Sly

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

— ধামা ধরা

আমি একবারে আমার সমস্যাগুলি সমাধান করি fix সুতরাং পরীক্ষাগুলি একাধিকবার ব্যর্থ হতে পারে তা আমাকে বিরক্ত করে না। আমি যদি এগুলি বিভক্ত করি তবে আমার একই ত্রুটিগুলি আসতে হবে তবে সমস্ত একবারে। আমি একবারে জিনিসগুলি ঠিক করা আরও সহজ মনে করি। আমি স্বীকার করি, এই উদাহরণস্বরূপ, শেষ দুটি দৃ .় সম্ভবত তাদের নিজস্ব পরীক্ষায় পুনরুদ্ধার করা যেতে পারে।

— ম্যাট এলেন

আপনার কেসটি খুব প্রতিনিধিত্বমূলক, এজন্যই নুনিটের টেস্টকেস - নুনিট.আর.পি?

— কেসটি

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

— রতকোক

Answer 4

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

@Test
public void testAlarmSent() {
    assertAllUnitsAvailable();
    assertNewAlarmMessages(0);

    pulseMainProcessor();

    assertAllUnitsAlerting();
    assertAllNotificationsSent();
    assertAllNotificationsUnclosed();
    assertNewAlarmMessages(1);
}

কোডটি আমার প্রত্যাশার সাথে আচরণ করছে সে বিষয়ে আমার আত্মবিশ্বাসী হওয়ার জন্য প্রক্রিয়াটির প্রতিটি পদক্ষেপে এটি থাকা শর্তগুলির প্রতিনিধিত্ব করে। যদি কোনও একক দৃ f়তা ব্যর্থ হয় তবে আমি যত্ন করি না যে বাকীগুলি এমনকি চালাবেন না; কারণ সিস্টেমের অবস্থা আর বৈধতা নেই, যারা পরবর্তী গবেষকেরা আমাকে কিছু মূল্যবান বলতাম না। * যদি assertAllUnitsAlerting()ব্যর্থ হয়েছে, তারপর আমি কি করতে জানতাম না assertAllNotificationSent()এর সফলতা বা ব্যর্থতা যতদিন না আমি নির্ধারিত কি পূর্বে ত্রুটি গচ্চা গেল এবং এটি সংশোধন।

(* - ঠিক আছে, তারা সম্ভবত সমস্যাটি ডিবাগ করার ক্ষেত্রে কার্যকর হতে পারে But তবে সবচেয়ে গুরুত্বপূর্ণ তথ্য, যা পরীক্ষাটি ব্যর্থ হয়েছিল, ইতিমধ্যে এটি পেয়েছে))

Comments

যখন আপনি এটি করেন যে আপনার নির্ভরশীল পরীক্ষাগুলির সাথে টেস্টিং ফ্রেমওয়ার্কগুলি ব্যবহার করা উচিত, এটি আরও ভাল (যেমন টেস্টং এই বৈশিষ্ট্যটিকে সমর্থন করে)

— কেমোডা

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

— এমডিএমএ

এটি একটি assertAlarmStatus (int সংখ্যাOfAlarmMessages) এ রিফ্যাক্টর সম্পর্কে আপনার মতামত কী ?;

— বোরজব

আপনার দৃser়পদগুলি খুব দুর্দান্ত পরীক্ষার নামের জন্য তৈরি করবে।

— বাইজর্ন টিপলিং

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

— কার্টেনডগ

Answer 5

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

class Service {
    Result process();
}

class Result {
    Inner inner;
}

class Inner {
    int number;
}

আমার পরীক্ষায় আমি কেবল পরীক্ষা করতে চাই যা শ্রেণীর ক্ষেত্রে service.process()সঠিক নম্বরটি দেয় Inner।

পরীক্ষার পরিবর্তে ...

@Test
public void test() {
    Result res = service.process();
    if ( res != null && res.getInner() != null ) Assert.assertEquals( ..., res.getInner() );
}

আমি করছি

@Test
public void test() {
    Result res = service.process();
    Assert.notNull(res);
    Assert.notNull(res.getInner());
    Assert.assertEquals( ..., res.getInner() );
}

Comments

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

— রেস্টুটা

আপনার Assert.notNullগুলি অপ্রয়োজনীয়, আপনার পরীক্ষাটি যদি কোনও শূন্য হয় তবে এনপিইতে ব্যর্থ হবে।

— সারা

এছাড়াও, আপনার প্রথম উদাহরণটি (এর সাথে if) যদি পাস resহয়null

— সারা

@ কাই নট নলগুলি অপ্রয়োজনীয়, আমি সম্মত, তবে আমি মনে করি যে ব্যতিক্রমের পরিবর্তে (এবং যদি আমি সঠিক বার্তা দিয়েও অলস না হই) তবে

— দৃ have় বক্তব্য রাখা ভাল er

ঠিক আছে, ব্যর্থ হ'ল একটি ব্যতিক্রমও ছুঁড়েছে এবং উভয় ক্ষেত্রেই আপনি সঠিক সারির সাথে একটি সরাসরি লিঙ্ক পাবেন যা এটি একটি সহবর্তী স্ট্যাক ট্রেস দিয়ে ছুঁড়েছে তাই ব্যক্তিগতভাবে আমি পরীক্ষার পূর্বশর্তগুলি দিয়ে পরীক্ষা না করানো চাই যা যাইহোক পরীক্ষা করা হবে। আমি একটি অনেলিয়ার à লা পছন্দ করবো Assert.assertEquals(..., service.process().getInner());, যদি লাইনটি "খুব দীর্ঘ" হয়ে যায় তবে নিষ্কাশিত ভেরিয়েবলগুলি দিয়ে সম্ভব

— সারার

Answer 6

আমি মনে করি যে প্রচুর মামলা রয়েছে যেখানে নিয়মের মধ্যে একাধিক দাবি লেখা বৈধ যে কোনও পরীক্ষায় কেবল একটি কারণে ব্যর্থ হওয়া উচিত।

উদাহরণস্বরূপ, কোনও ফাংশনটি কল্পনা করুন যা একটি তারিখের স্ট্রিংকে বিশ্লেষণ করে:

function testParseValidDateYMD() {
    var date = Date.parse("2016-01-02");

    Assert.That(date.Year).Equals(2016);
    Assert.That(date.Month).Equals(1);
    Assert.That(date.Day).Equals(0);
}

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

Answer 7

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

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

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

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

উদাহরণ (এটি একাধিক ফাইলে বিভক্ত হবে):

namespace Tests.AcctTests
{
    [TestFixture]
    public class no_events
    {
        private Acct _acct;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
        }

        [Test]
        public void balance_0() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }

    [TestFixture]
    public class try_withdraw_0
    {
        private Acct _acct;
        private List<string> _problems;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
            Assert.That(_acct.Balance, Is.EqualTo(0));
            _problems = _acct.Withdraw(0m);
        }

        [Test]
        public void has_problem() {
            Assert.That(_problems, Is.EquivalentTo(new string[] { "Withdraw amount must be greater than zero." }));
        }

        [Test]
        public void balance_not_changed() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }

    [TestFixture]
    public class try_withdraw_negative
    {
        private Acct _acct;
        private List<string> _problems;

        [SetUp]
        public void SetUp() {
            _acct = new Acct();
            Assert.That(_acct.Balance, Is.EqualTo(0));
            _problems = _acct.Withdraw(-0.01m);
        }

        [Test]
        public void has_problem() {
            Assert.That(_problems, Is.EquivalentTo(new string[] { "Withdraw amount must be greater than zero." }));
        }

        [Test]
        public void balance_not_changed() {
            Assert.That(_acct.Balance, Is.EqualTo(0m));
        }
    }
}

Comments

এই ক্ষেত্রে আপনি কীভাবে টেস্টকেস ইনপুট পরিচালনা করবেন?

— সাইমন গিলবি

সুতরাং, আমার বর্তমান সংস্থায়, আপনি যা দেখান তার সাথে আমাদের 20,000+ ইউনিট পরীক্ষা রয়েছে। এটি দুঃস্বপ্ন। পরীক্ষার সেটআপ কোডটির বেশিরভাগটি অনুলিপি / আটকানো হয়, ফলস্বরূপ ভুল পরীক্ষা সেটআপ এবং অবৈধ পরীক্ষাগুলি পাস হয়। প্রতিটি [Test]পদ্ধতির জন্য, সেই শ্রেণিকে পুনরায় ইনস্ট্যান্ট করা হয় এবং [SetUp]পদ্ধতিটি আবার কার্যকর করা হয়। এটি .NET আবর্জনা সংগ্রাহককে হত্যা করে এবং টেস্টগুলি অত্যন্ত ধীরে ধীরে চালিত করে: স্থানীয়ভাবে 5+ মিনিট, বিল্ড সার্ভারে 20+ মিনিট। 20 কে পরীক্ষা প্রায় 2 - 3 মিনিটের মধ্যে চালানো উচিত। আমি এই টেস্টিং স্টাইলটি মোটেও সুপারিশ করব না , বিশেষত বড়-ইশ টেস্ট স্যুটটির জন্য।

— ফোরস্পাস্টমিডনাইট

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

— এখনও_ড্রিমিং_১১

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

— এখনও_ড্রিমিং_1

@ still_dreaming_1 wrt "দায়িত্বজ্ঞানহীন প্রোগ্রামারস": আমি সম্মত হই যে এই আচরণটি একটি বড় সমস্যা। যাইহোক, পরীক্ষার কাঠামোর এই ধরণের সত্য বা আরও খারাপ জন্য এই ধরণের আচরণকে আমন্ত্রণ জানায়। খারাপ বিকাশের অনুশীলনগুলি বাদ দিয়ে, এই ফর্মটির বিষয়ে আমার প্রধান আপত্তি হ'ল এটি সত্যই পরীক্ষার কার্যকারিতাটিকে হত্যা করে। ধীর চলমান টেস্ট স্যুটের চেয়ে খারাপ আর কিছু নেই। একটি ধীর চলমান টেস্ট স্যুট মানে লোকেরা স্থানীয়ভাবে পরীক্ষা চালাবে না এবং এমনকি মধ্যবর্তী বিল্ডগুলিতে এড়িয়ে চলে যাওয়ার প্রলোভন দেখায় - আবারও লোকজনের সমস্যা, তবে এটি ঘটে - যা আপনার দ্রুত চলমান পরীক্ষা চালিয়ে যাওয়ার নিশ্চয়তা দিয়ে এড়ানো যেতে পারে all সঙ্গে.

— ফোরস্পাস্টমিডনাইট

Answer 8

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

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

Comments

আপনি যদি একাধিক অবস্থার একক দৃ into়তার সাথে সংমিশ্রণ করছেন তবে ব্যর্থতার পরে আপনারা সকলেই জানেন যে এটি ব্যর্থ। একাধিক দৃ With়তার সাথে আপনি তাদের কয়েকটি সম্পর্কে বিশেষত জানেন (ব্যর্থতা পর্যন্ত রয়েছে) know ফিরে আসা অ্যারে যাচাই করার জন্য একটি একক মান রয়েছে তা বিবেচনা করুন: এটি নাল নয় তা পরীক্ষা করুন, তারপরে এর ঠিক একটি উপাদান রয়েছে এবং তারপরে সেই উপাদানটির মান। (প্ল্যাটফর্মের উপর নির্ভর করে) কেবলমাত্র মানটি পরীক্ষা করা অবিলম্বে একটি নাল ডিসেফারেন্স দিতে পারে (নাল দৃser়তা ব্যর্থ হওয়ার চেয়ে কম সহায়ক) এবং অ্যারের দৈর্ঘ্য পরীক্ষা করে না।

— রিচার্ড

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

— গুফা

থাম্বের বিধি: যদি আপনার পরীক্ষায় একাধিক দাবি থাকে তবে প্রত্যেকের আলাদা আলাদা বার্তা থাকা উচিত। তাহলে আপনার এই সমস্যা নেই।

— অ্যান্টনি

এবং এনক্রাঞ্চের মতো মানের মানের রানার ব্যবহার করে পরীক্ষা টেস্ট কোড এবং পরীক্ষার অধীনে থাকা কোড উভয়ই পরীক্ষায় কোনটি ব্যর্থ হয়েছে ঠিক ঠিক তা দেখাবে।

— ফোরস্পাস্টমিডনাইট

Answer 9

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

String actual = "val1="+val1+"\nval2="+val2;
assertEquals(
    "val1=5\n" +
    "val2=hello"
    , actual
);

এটি আমাকে একবারে সমস্ত ব্যর্থ প্রতিবেদনগুলি দেখতে দেয়। আমি বেশ কয়েকটি লাইন ব্যবহার করি কারণ বেশিরভাগ আইডিই পাশের পাশাপাশি তুলনা ডায়ালগে স্ট্রিং পার্থক্য প্রদর্শন করবে।

Answer 10

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

@Test
test_Is_Date_segments_correct {

   // It is okay if you have multiple asserts checking dd, mm, yyyy, hh, mm, ss, etc. 
   // But you would not have any assert statement checking if it is string or number,
   // that is a different test and may be with multiple or single assert statement.
}

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

Answer 11

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

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

Answer 12

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

যথাযথ ইউনিট পরীক্ষাগুলি ঠিক এক কারণে ব্যর্থ হওয়া উচিত, এজন্য আপনাকে প্রতি ইউনিট পরীক্ষায় একটি প্রতিস্থাপন ব্যবহার করা উচিত।

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

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

সুতরাং, কেবল কোডের স্বচ্ছতা এবং পরীক্ষার ফলাফলের স্বচ্ছতার দিকে মনোনিবেশ করুন এবং এটি তার বিপরীতে পরিবর্তনের পরিবর্তে আপনি যে পরিমাণ দৃ .়সংকল্প ব্যবহার করছেন তার দিকনির্দেশনা দিন।

Answer 13

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

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

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

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

Answer 14

এই প্রশ্নটি স্প্যাগেটি এবং লাসাগন কোড ইস্যুগুলির মধ্যে ভারসাম্যের ক্লাসিক সমস্যার সাথে সম্পর্কিত।

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

কিছু ব্যতিক্রম আছে, তবে এক্ষেত্রে দুলটি মাঝখানে রেখে দেওয়া উত্তর answer

Answer 15

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

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