ইউনিট টেস্টিংয়ে নতুন, কীভাবে দুর্দান্ত পরীক্ষা লিখবেন? [বন্ধ]

Question

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

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

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

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

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

সম্পাদনা করুন: আমি স্ট্যাক ওভারফ্লোকে ধন্যবাদ জানাতে চাই, আমার 15 মিনিটেরও কম সময়ে দুর্দান্ত ইনপুট হয়েছিল যা অনলাইনে পড়ার ঘন্টাগুলি বেশিরভাগ উত্তর দিয়েছিল যে আমি সবে করেছি।

Comments

এটি ইউনিট পরীক্ষার জন্য সেরা বই: manning.com/osherove এটি ইউনিট পরীক্ষার জন্য সমস্ত সেরা অনুশীলন, করণীয় এবং না করা সম্পর্কে ব্যাখ্যা করে।

— এরভি বি

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

— টমাস টেম্পেলম্যান

Answer 1

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

আমি মনে করি আপনি এটি ভুল করছেন।

একটি ইউনিট পরীক্ষা করা উচিত:

• একটি পদ্ধতি পরীক্ষা
• এই পদ্ধতিতে কিছু নির্দিষ্ট যুক্তি সরবরাহ করুন
• ফলাফল প্রত্যাশিত হিসাবে পরীক্ষা

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

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

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

testAdd()
{
    int x = 5;
    int y = -2;
    int expectedResult = 3;
    Calculator calculator = new Calculator();
    int actualResult = calculator.Add(x, y);
    Assert.AreEqual(expectedResult, actualResult);
}

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

Comments

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

— পিক্সেলাস্টিক

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

— ওয়েস

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

— রোবারটাইমেন

Answer 2

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

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

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

সমস্ত সাধারণ উদাহরণ function square(number)যেমন দুর্দান্ত এবং সমস্ত, এবং সম্ভবত পরীক্ষার প্রচুর সময় ব্যয় করার জন্য খারাপ প্রার্থীরা। যেগুলি গুরুত্বপূর্ণ ব্যবসার যুক্তি দেয়, সেখানে পরীক্ষাগুলি গুরুত্বপূর্ণ ts প্রয়োজনীয়তা পরীক্ষা করুন। শুধু নদীর গভীরতানির্ণয় পরীক্ষা করবেন না। যদি প্রয়োজনীয়তাগুলি পরিবর্তন হয় তবে অনুমান করুন কী, পরীক্ষাগুলিও অবশ্যই তা করা উচিত।

টেস্টিংটি আক্ষরিকভাবে সেই ফাংশন foo অনুরোধ করা ফাংশন বার 3 বার পরীক্ষা করা উচিত নয়। এটা ভুল। ফলাফল এবং পার্শ্ব-প্রতিক্রিয়াগুলি সঠিক কিনা তা পরীক্ষা করুন, অভ্যন্তরীণ যান্ত্রিকগুলি নয়।

Comments

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

— পিক্সেলাস্টিক

একটি নিখুঁত সাম্প্রতিক উদাহরণ। আমার খুব সাধারণ কাজ ছিল। সত্য এটি পাস করুন, এটি একটি কাজ করে, মিথ্যা এটি অন্যটি করে। খুব সহজ. ফাংশনটি এটি করতে ইচ্ছুক কী তা নিশ্চিত করে তা পরীক্ষা করে দেখতে 4 টি পরীক্ষা করে দেখেছি। আমি আচরণটি কিছুটা পরিবর্তন করি। পরীক্ষা চালান, POW একটি সমস্যা। মজার বিষয় হ'ল অ্যাপ্লিকেশনটি ব্যবহার করার সময় সমস্যাটি প্রকাশ পায় না, এটি কেবল জটিল ক্ষেত্রে ঘটে। পরীক্ষার কেসটি এটি খুঁজে পেয়েছিল এবং আমি নিজেকে কয়েক ঘন্টা মাথা ব্যথা থেকে বাঁচালাম।

— দিমিত্রি লিখটেন

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

— গ্রিনস্টিক

Answer 3

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

বিদ্যমান কোডটিকে টেস্ট চালিত বিকাশে সরানো হচ্ছে

আমি স্বীকৃত উত্তরের বইয়ের সুপারিশটিকে দ্বিতীয় করেছিলাম, তবে এর বাইরেও উত্তরগুলিতে আরও তথ্যের সাথে যুক্ত রয়েছে।

Comments

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

— দিমিত্রি লিখটেন

সম্ভবত গ্রহণযোগ্য উত্তর পরিবর্তন হয়েছে। লিনেক্সের একটি উত্তর রয়েছে যা রায় ওশেরোভ, ম্যানিং

— থিম

Answer 4

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

আপনার পরীক্ষা ছোট রাখুন: প্রয়োজন অনুযায়ী একটি পরীক্ষা।

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

Comments

ধন্যবাদ, এটি একবারে কেবলমাত্র ছোট প্রয়োজনের জন্য ছোট ছোট পরীক্ষা করার জন্য বোধগম্য। পাঠ শিখেছি।

— পিক্সেলাস্টিক

Answer 5

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

Comments

ধন্যবাদ! আমার অনুভূতি হয়েছিল যে আমি এটি ভুল করছি, তবে কেউ আমাকে আসলে বললে ভাল হয়।

— পিক্সেলাস্টিক

Answer 6

যে পদ্ধতিটি পরীক্ষা চলছে এটি লেখার আগে একটি ইউনিট টেস্ট লেখার চেষ্টা করুন।

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

পদ্ধতির ফলাফলগুলি কীভাবে পায় তা নয়, আপনি সর্বদা পদ্ধতির ফলাফলগুলি পরীক্ষা করে দেখতে হবে।

Comments

হ্যাঁ, আমি পদ্ধতিগুলি ইতিমধ্যে লিখিত না বাদে আমি তা করতে সক্ষম হতে চাই। আমি কেবল তাদের পরীক্ষা করতে চাই। আমি ভবিষ্যতে পদ্ধতির আগে পরীক্ষা লিখব, তাই।

— পিক্সেলাস্টিক

@ পিক্সেলাস্টিক ভান করে যে পদ্ধতিগুলি লেখা হয়নি?

— প্রতিশ্রুতিবদ্ধ

Answer 7

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

When I'm writing tests for a method, I have the feeling of rewriting a second time what I          
already wrote in the method itself.
My tests just seems so tightly bound to the method (testing all codepath, expecting some    
inner methods to be called a number of times, with certain arguments), that it seems that
if I ever refactor the method, the tests will fail even if the final behavior of the   
method did not change.

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

Comments

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

— পিক্সেলাস্টিক

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

— hvgotcodes

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

— hvgotcodes