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

reserveInventory(itemId, qty) বৈশিষ্ট্যের জন্য একটি স্পষ্ট উদাহরণ আছে:\n\nকনট্র্যাক্টটি বলে দিতে পারে qty একটি ধনাত্মক পূর্ণসংখ্যা হতে হবে, ফাংশনটি অ্যাটমিক হবে, এবং কখনো নেতিবাচক স্টক তৈরি করা যাবে না। এটি তৎক্ষণাৎ উচ্চ-সিগন্যাল টেস্টগুলো সুপারিশ করে: qty = 0, qty = 1, প্রাপ্যতার চেয়ে বেশি qty, কনকারেন্ট কল, এবং মাঝপথে জোরপূর্বক ডাটাবেস এরর।\n\nআপনি যদি Koder.ai এর মত একটি ভাইব-কোডিং টুল ব্যবহার করেন, একই ওয়ার্কফ্লো প্রযোজ্য: প্রথমে চ্যাটে কনট্র্যাক্ট লিখুন, তারপর সেই কনট্র্যাক্ট সরাসরি সীমান্ত, ব্যর্থতা মোড, এবং "কখনো হবে না" তালিকায় আক্রমণ করে টেস্ট জেনারেট করুন।\n\n## প্রম্পট প্যাটার্ন: উচ্চ-সিগন্যাল টেস্ট ব্লুপ্রিন্ট\n\nএই Claude Code টেস্ট জেনারেশন প্রম্পটটি ব্যবহার করুন যখন আপনি কম টেস্ট চান কিন্তু প্রতিটি টেস্ট কাজ চালায়। মূল কৌশল হল প্রথমে একটি টেস্ট প্ল্যান বাধ্য করা, তারপর আপনি সেই প্ল্যান অনুমোদন করলে টেস্ট কোড জেনারেট করা।\n\ntext\nYou are helping me write HIGH-SIGNAL unit tests.\n\nContext\n- Language/framework: <fill in>\n- Function/module under test: <name + short description>\n- Inputs: <types, ranges, constraints>\n- Outputs: <types + meaning>\n- Side effects/external calls: <db, network, clock, randomness>\n\nContract (keep it small)\n1) Preconditions: <what must be true>\n2) Postconditions: <what must be true after>\n3) Error behavior: <how failures are surfaced>\n\nTask\nPHASE 1 (plan only, no code):\nA) Propose 6-10 tests max. Do not include “happy path” unless it protects an invariant.\nB) For each test, state: intent, setup, input, expected result, and WHY it is high-signal.\nC) Invariants: list 3-5 invariants and how each will be asserted.\nD) Boundary matrix: propose a small matrix of boundary values (min/max/empty/null/off-by-one/too-long/invalid enum).\nE) Failure modes: list negative tests that prove safe behavior (no crash, no partial write, clear error).\nStop after PHASE 1 and ask for approval.\n\nPHASE 2 (after approval):\nGenerate the actual test code with clear names and minimal mocks.\n\n\nএকটি ব্যবহারিক কৌশল হল boundary matrix কে একটুকু টেবিলে বাধ্য করা যাতে ফাঁকগুলো দ্রুত দৃশ্যমান হয়:\n\n| Dimension | Valid edge | Just outside | “Weird” value | Expected behavior |\n|---|---|---|---|---|\n| length | 0 | -1 | 10,000 | error vs clamp vs accept |\n\nযদি Claude 20টি টেস্ট প্রস্তাব করে, চাপ দিন—একই ধরনের কেসগুলো একত্র করুন এবং কেবল সেইগুলো রাখুন যা বাস্তবে একটি বাগ ধরবে (অফ-বাই-ওয়ান, ভুল এরর টাইপ, নিঃশব্দ ডাটা লস, ভাঙা ইনভারিয়েন্ট)।\n\n## ধাপে ধাপে: প্রম্পট চালান এবং আউটপুটকে টেস্টে বদলান\n\nএকটি ছোট, কংক্রীট কনট্র্যাক্ট দিয়ে শুরু করুন। ফাংশন সিগনেচার, ইনপুট ও আউটপুটের সংক্ষিপ্ত বর্ণনা, এবং বিদ্যমান টেস্ট (যেমন তারা কেবল হ্যাপি-পাথ হলে ও) পেস্ট করুন। এটি মডেলকে কোড সম্পর্কিত রাখতে সাহায্য করে—এটা অনুমান না করে।\n\nএরপর, যেকোনো টেস্ট কোড চাওয়ার আগে একটি ঝুঁকি টেবিল (risk table) চাওয়া শুরু করুন। তিনটি কলাম বাধ্য করুন: সীমান্ত কেস, ব্যর্থতা মোড, এবং ইনভারিয়েন্ট। প্রতি সারিতে এক বাক্য যোগ করুন: “কেন এটি ভেঙে যেতে পারে।” একটি সাদামাঠা টেবিল ফাঁকগুলো দ্রুত প্রকাশ করে।\n\nতারপর সবচেয়ে ছোট টেস্ট সেট বেছে নিন যেখানে প্রতিটি টেস্টের একটি অনন্য বাগ ধরার উদ্দেশ্য আছে। যদি দুইটি টেস্ট একই কারণে ব্যর্থ করে, শক্তিশালীটিকে রাখুন।\n\nএকটি ব্যবহারিক নির্বাচন নিয়ম:\n\n- বিভিন্ন সীমান্তে ধাক্কা দেওয়া টেস্ট রাখুন (min, max, empty, off-by-one).\n- ব্যর্থতার সময় নিরাপদ আচরণ প্রমাণ করা টেস্ট রাখুন (স্পষ্ট এরর, আংশিক লেখা নেই, ক্র্যাশ নয়)।\n- ইনভারিয়েন্ট অ্যাসার্ট করা টেস্ট রাখুন (অর্ডারিং, টোটাল, আইডেমপোটেন্সি, ডুপ্লিকেট নেই)।\n- শুধুমাত্র “নর্মাল ইনপুটে কাজ করে” পুনরাবৃত্ত টেস্টগুলো কেটে দিন।\n\nশেষে, প্রতিটি টেস্টের জন্য একটি ছোট ব্যাখ্যা দাবী করুন: যদি টেস্ট ফেল করে তাহলে কোন বাগটি ধরা পড়বে। যদি ব্যাখ্যাটি ধোঁয়াশা ("বিহেভিয়ার ভ্যালিডেট করে") হয়, টেস্টটি সম্ভবত কম-মূল্যের।\n\n## কীভাবে ইনভারিয়েন্টগুলোকে অ্যাসারশনে এনকোড করবেন\n\nইনভারিয়েন্ট হল এমন নিয়ম যা যেকোনো বৈধ ইনপুটে সত্য থাকা উচিত। ইনভারিয়েন্ট-ভিত্তিক টেস্টিংয়ে আপনি প্রথমে নিয়মটিকে সোজা ভাষায় লিখেন, তারপর সেটিকে এমন অ্যাসারশনে রূপান্তর করেন যা স্পষ্টভাবে ফেল করে।\n\n1 বা 2টি ইনভারিয়েন্ট বেছে নিন যা বাস্তবে আপনাকে বাগ থেকে রক্ষা করে। ভাল ইনভারিয়েন্টগুলো সাধারণত সেফটি (ডাটা লস না হওয়া), কনসিস্টেন্সি (একই ইনপুট → একই আউটপুট), বা সীমা (ক্যাপ ছাড়িয়ে না যাওয়া) সম্পর্কে হয়।\n\n### একটি ইনভারিয়েন্টকে প্রমাণযোগ্য চেক বানান\n\nইনভারিয়েন্টটিকে একটি সংক্ষিপ্ত বাক্যে লিখুন, তারপর সিদ্ধান্ত নিন আপনার টেস্ট কোন প্রমাণ দেখতে পাবে: রিটার্ন ভ্যালু, স্টোরড ডেটা, এমিট করা ইভেন্ট, বা ডিপেন্ডেন্সি কল। শক্তিশালী অ্যাসারশন আউটকাম এবং সাইড-এফেক্ট উভয়ই চেক করে, কারণ অনেক বাগ লুকায় "ওকে রিটার্ন করেছে কিন্তু ভুল লিখেছে।"\n\nউদাহরণ: কুপন অ্যাপ্লাই করার একটি ফাংশন থাকলে:\n\n- ইনভারিয়েন্ট: ফাইনাল টোটাল কখনও নেগেটিভ নয়।\n- ইনভারিয়েন্ট: একই কুপন দুইবার অ্যাপ্লাই করলে দুইবার ডিসকাউন্ট হয় না।\n\nএখন এগুলোকে কনক্রিট অ্যাসারশনে রূপান্তর করুন যা প্রমাণযোগ্য:\n\nts\nexpect(result.total).toBeGreaterThanOrEqual(0)\nexpect(db.getOrder(orderId).discountCents).toBe(originalDiscountCents)\n\n\nঅস্পষ্ট অ্যাসারশন যেমন “returns expected result” এড়িয়ে চলুন। নির্দিষ্ট নিয়ম (নন-নেগেটিভ), এবং নির্দিষ্ট সাইড-এফেক্ট (একবারে ডিসকাউন্ট সেভ হয়) অ্যাসার্ট করুন।\n\n### একটি কাউন্টারএক্সাম্পল নোট যোগ করুন যাতে টেস্ট তীক্ষ্ণ থাকে\n\nপ্রতিটি ইনভারিয়েন্টের জন্য টেস্টে ছোট নোট যোগ করুন যে কোন ডেটা এটি ভঙ্গ করবে। এটি টেস্টটিকে ভবিষ্যতে হ্যাপি-পাথ চেকে পরিণত হওয়া থেকে রাখে।\n\nএকটি সহজ প্যাটার্ন যা সময়ের সাথে টিকে থাকে:\n\n- ইনভারিয়েন্ট টেস্ট নামেই রাখুন।\n- আউটপাটে ইনভারিয়েন্ট অ্যাসার্ট করুন।\n- মূল সাইড-এফেক্ট (বা তার অভাব) অ্যাসার্ট করুন।\n- একটি কমেন্ট যোগ করুন যে কোন কেস ভঙ্গ করবে (উদাহরণ: অনেক বড় কুপন ভ্যালু বা ডুপ্লিকেট অ্যাপ্লিকেশন)।\n\n## ব্যর্থতা মোড: নিরাপদ ব্যর্থতাকে প্রমাণ করে এমন টেস্ট লিখুন\n\nউচ্চ-সিগন্যাল টেস্টগুলো প্রায়শই সেগুলোই যা আপনার কোড নিরাপদভাবে ব্যর্থ করে তা নিশ্চিত করে। যদি মডেল কেবল হ্যাপি-পাথ টেস্ট লিখে, আপনি প্রায় কিছুই শিখেন না যে ফিচার কিভাবে ইনপুট ও ডিপেন্ডেন্সি মেস হলে আচরণ করে।\n\nশুরু করুন এই সিদ্ধান্ত নিয়ে যে এই ফিচারের জন্য “নিরাপদ” মানে কী। এটা কি টাইপকৃত এরর রিটার্ন করে? কি এটি একটি ডিফল্টে ফ্যাকব্যাক করে? এটি কি একবার রিট্রাই করে থামে? এক বাক্যে প্রত্যাশিত আচরণ লিখুন, তারপর টেস্টগুলোকে তা প্রমাণ করতে বলুন।\n\nযখন আপনি Claude Code কে ব্যর্থতা মোড টেস্ট চান তখন লক্ষ্য কড়া রাখুন: সিস্টেম ভাঙার উপায়গুলো কভার করুন, এবং আপনি যা চান তা স্পষ্টভাবে অ্যাসার্ট করুন। একটি দরকারী লাইন: “কম টেস্ট কিন্তু শক্তিশালী অ্যাসারশন রাখুন বেশি পাথাল টেস্টের চেয়ে।”\n\nভালো ফল দেয় এমন ব্যর্থতা ক্যাটেগরিগুলো:\n- খারাপ ইনপুট: অবৈধ ফরম্যাট, অনুপস্থিত আবশ্যক ক্ষেত্র, আউট-অফ-রেঞ্জ মান\n- ডিপেন্ডেন্সি ফেল: টাইমআউট, 500s, খালি রেসপন্স, করাপ্টেড পে-লোড\n- অর্ডারিং সমস্যা: আউট-অফ-অর্ডার ইভেন্ট, ডুপ্লিকেট, আংশিক লেখা\n- concurrency: রেসিং আপডেট, ইডেমপোটেন্সি চেক\n- রিকভারি আচরণ: কখন আপনি এরর রিটার্ন করেন বনাম ফ্যাকব্যাক বা রিট্রাই \nউদাহরণ: একজন এন্ডপয়েন্ট আছে যে একজন ইউজার তৈরি করে এবং একটি ওয়েলকাম ইমেইল সার্ভিস কল করে। একটি নিম্ন-মূল্যের টেস্ট কেবল “201 রিটার্ন” চেক করে। একটি উচ্চ-সিগন্যাল ব্যর্থতা টেস্ট নিশ্চিত করে যে যদি ইমেইল সার্ভিস টাইমআউট করে, আপনি অথবা (a) ব্যবহারকারী তৈরি করেন এবং 201 রিটার্ন করেন সাথে একটি “email_pending” ফ্ল্যাগ, অথবা (b) 503 রিটার্ন করে এবং ব্যবহারকারী তৈরি করেন না। একটি আচরণ বেছে নিন এবং উভয় রেসপন্স ও সাইড-এফেক্ট assert করুন।\n\nএছাড়া পরীক্ষা করুন কি আপনি লিক করেন না। যদি ভ্যালিডেশন ফেল করে, নিশ্চিত করুন কিছুই ডাটাবেসে লেখা হয়নি। যদি ডিপেন্ডেন্সি করাপ্টেড পে-লোড দেয়, নিশ্চিত করুন আপনি আনহ্যান্ডেল্ড এক্সসেপশন থ্রো করেন না বা র ফলভাবে কাঁচা স্ট্যাকট্রেস রিটার্ন করেন না।\n\n## কমন ট্র্যাপ যা নিচ-মূল্যের টেস্ট তৈরি করে\n\nকম-মূল্যের টেস্ট সেট সাধারণত তখন হয় যখন মডেল ভলিউমের জন্য রিওয়ার্ড পায়। যদি আপনার Claude Code টেস্ট জেনারেশন প্রম্পট “20 ইউনিট টেস্ট” চায়, আপনি প্রায়ই ছোট ভ্যারিয়েশন পেয়ে যাবেন যা দেখতেও বিস্তৃত কিন্তু আসলে নতুন কিছু ধরছে না।\n\nসাধারণ ট্র্যাপগুলো:\n\n- লুক-আলাইক টেস্ট: একই "ভ্যালিড ইনপুট" টেস্ট বিভিন্ন স্ট্রিং বা সংখ্যায় পুনরাবৃত্তি।\n- কোডের অনুকরণ করে টেস্ট লেখা: প্রাইভেট স্টেপ বা হেল্পার কল assert করা, পরিবর্তে পর্যবেক্ষণযোগ্য আচরণ assert করা।\n- সবকিছু মক করা: ডাটাবেস, ঘড়ি, নেটওয়ার্ক, কনফিগ—সবকিছুই প্রতিস্থাপন করা।\n- দুর্বল অ্যাসারশন: কেবল "কোন এরর নেই", "নাল নয়", বা "স্ট্যাটাস 200" চেক করা।\n- গন্দা শেয়ার্ড স্টেট: সিডেড ডাটা রেখে যাওয়া, মডিফাইড গ্লোবালস, বা ক্যাশড ভ্যালু।\n\nউদাহরণ: একটি "create user" ফাংশন ধরুন। দশটি হ্যাপি-পাথ টেস্ট ইমেইল স্ট্রিং ভ্যারিয়েশন করতে পারে এবং গুরুত্বপূর্ণ বিষয়গুলো মিস করে: ডুপ্লিকেট ইমেইল প্রত্যাখ্যান, খালি পাসওয়ার্ড হ্যান্ডেল, এবং নিশ্চিত করা যে রিটার্ন করা ইউজার আইডি ইউনিক ও স্থির।\n\nরিভিউতে সহায়ক গার্ডরেইল: \n- প্রতিটি টেস্টকে কাভার করা ঝুঁকিটি নাম দিতে বলুন (সীমান্ত, ব্যর্থতা মোড, বা ইনভারিয়েন্ট)।\n- কেবল ইমপ্লিমেন্টেশন-অবসার্ভেবল চেক এড়িয়ে চলুন যদি তা পর্যবেক্ষণযোগ্য আচরণ বদলায় না।\n- মকলগুলো ন্যূনতম রাখুন, এবং যখন সম্ভব হলে বাস্তব ইন্টিগ্রেশন পয়েন্টে কিছু টেস্ট রাখতে বলুন।\n- শক্তিশালী অ্যাসারশন দাবি করুন: সঠিক আউটপুট, স্টেট চেঞ্জ, এবং এরর টাইপ/মেসেজ।\n- ক্লিনআপ নিয়ম রাখুন যাতে টেস্টগুলো অর্ডারের উপর নির্ভর না করে।\n\n## উদাহরণ: এক ফিচারকে একটি ছোট, শক্ত টেস্ট সেটে পরিণত করা\n\nধরুন একটি ফিচার: চেকআউটে কুপন কোড প্রয়োগ করা।\n\nকনট্র্যাক্ট (ছোট এবং টেস্টেবল): একটি কার্ট সাবটোটাল সেন্টে এবং অপশনাল কুপন দিলে একটি ফাইনাল টোটাল সেন্টে রিটার্ন করুন। নিয়ম: পার্সেন্টেজ কুপন নিকটতম সেন্ট পর্যন্ত নিচে রাউন্ড করে, নির্দিষ্ট কুপন নির্দিষ্ট পরিমাণ বিয়োগ করে, এবং টোটাল কখনো 0 এর নিচে যায় না। একটি কুপন অবৈধ, এক্সপায়ার্ড, বা ইতিমধ্যেই ব্যবহৃত হতে পারে।\n\n"applyCoupon()"-এর জন্য শুধু টেস্ট চাইবেন না। সীমান্ত কেস টেস্টিং, ব্যর্থতা মোড টেস্ট, এবং এই কনট্র্যাক্ট-ভিত্তিক ইনভারিয়েন্ট চাওয়া।\n\n### এজ-কেসগুলো যাতে এজ আচরণ ফোর্স করে\n\nগাণিতিক বা ভ্যালিডেশনে ভাঙ্গতে পারে এমন ইনপুট বেছে নিন: একটি খালি কুপন স্ট্রিং, subtotal = 0, ন্যূনতম স্পেন্ডের ঠিক নীচে ও উপরে থাকা subtotal, ফিক্সড ডিসকাউন্ট subtotal থেকে বড়, এবং 33% মত একটি শতাংশ যা রাউন্ডিং তৈরি করে।\n\n### নিরাপদ আচরণ প্রমাণ করতে ব্যর্থতা মোডগুলো\n\nধরুন কুপন লুকআপ ফেল করতে পারে এবং স্টেট ভুল হতে পারে: কুপন সার্ভিস ডাউন, কুপন এক্সপায়ার্ড, বা কুপন ইতিমধ্যেই এই ইউজার দ্বারা রিডিম্ড। টেস্টটি পরের কি হয় তা প্রমাণ করা উচিত (কুপন প্রত্যাখ্যান, স্পষ্ট এরর, মোট অপরিবর্তিত)।\n\nএকটি ন্যূনতম, উচ্চ-সিগন্যাল টেস্ট সেট (5 টেস্ট) এবং প্রতিটির কি ধরে ধরবে:\n\n- খালি বা হোয়াইটস্পেস-শুধু কোড প্রত্যাখ্যান: খালি কুপন ভালিড মনে করার বাগ ধরবে এবং ট্রিমিং সমস্যা বের করে।\n- পার্সেন্ট কুপন রাউন্ডিং (subtotal 101, 33%): রাউন্ডিং ভুল এবং সেন্ট-অফ-বাই-ওয়ান ধরবে।\n- ফিক্সড ডিসকাউন্ট subtotal থেকে বেশি (subtotal 500, discount 1000): টোটাল কখনও নেগেটিভ হবে না এই ইনভারিয়েন্ট প্রমাণ করবে।\n- ন্যূনতম স্পেন্ড সীমা (subtotal 999 বনাম 1000): ভুল তুলনা লজিক (< বনাম <=) ধরবে।\n- কুপন লুকআপ ফেল বা টাইমআউট: নিরাপদ ফ্যালব্যাক (কোন ডিসকাউন্ট প্রয়োগ নয়) এবং স্থিতিশীল এরর হ্যান্ডলিং প্রমাণ করবে।\n\nযদি এগুলো পাস করে, আপনি ডুপ্লিকেট হ্যাপি-পাথ টেস্ট ছাড়া সাধারণ ভাঙ্গন বিন্দুগুলো কভার করেছেন।\n\n## উচ্চ-সিগন্যাল AI-জেনারেটেড টেস্টের দ্রুত চেকলিস্ট\n\nমডেল জেনারেট করেছে সেটি গ্রহণ করার আগে একটি দ্রুত মান যাচাই করুন। লক্ষ্য হলো প্রতিটি টেস্ট যে একটি নির্দিষ্ট, সম্ভাব্য বাগ থেকে আপনাকে রক্ষা করে।\n\nগেইট হিসেবে এই চেকলিস্ট ব্যবহার করুন:\n\n- ইনপুট প্রতি সীমান্ত: প্রতিটি ইনপুট ফিল্ডের জন্য অন্তত একটি এজ কেস (খালি বনাম হোয়াইটস্পেস-শুধু, সর্বোচ্চ দৈর্ঘ্য, 0 বনাম নেগেটিভ, অপশনাল ফিল্ড মিসিং, সীমার ঠিক পরে)।\n- ডিপেন্ডেন্সি ফেল: অন্তত একটি টেস্ট যেখানে একটি ডিপেন্ডেন্সি ম্যালফাংশন করে (ডিবি টাইমআউট, তৃতীয়-পক্ষ API 500, এক্সপায়ার্ড অথ টোকেন)। নিরাপদ আচরণ প্রমাণ করুন (স্পষ্ট এরর, কোনো আংশিক লেখা নেই)।\n- ইনভারিয়েন্টসহ শক্তিশালী অ্যাসারশন: 1–3 নিয়ম বেছে নিন এবং সরাসরি অ্যাসার্ট করুন। "রেসপন্স OK" ধরনের অস্পষ্ট অ্যাসারশন এড়িয়ে চলুন।\n- প্রতিটি টেস্ট একটি অনন্য বাগ: প্রতিটি টেস্ট নাম পড়ে নিজেকে জিজ্ঞাসা করুন, “এই টেস্ট কোন সুনির্দিষ্ট বাগ ধরবে?” যদি দুইটি টেস্ট একই প্রশ্নের উত্তর দেয়, একে মিশ্রিত করুন।\n- রিমুভাল টেস্ট: একটি টেস্ট মুছে ফেলুন—যদি কিছুই গুরুত্বপূর্ণ হারায় না (কোন সীমা, ব্যর্থতা মোড, বা ইনভারিয়েন্ট), এটি থাকার যোগ্য ছিল না।\n\nএকটি দ্রুত ব্যবহারিক কৌশল জেনারেশনের পরে: টেস্টগুলোর নাম পরিবর্তন করে রাখুন “should <behavior> when <edge condition>” এবং “should not <bad outcome> when <failure>” শৈলীতে। যদি আপনি পরিষ্কারভাবে নাম রাখতে না পারেন, তারা ফোকাসড নয়।\n\nযদি আপনি Koder.ai দিয়ে অ্যাপ বানান, এই চক্রটি সেখানে চালান (koder.ai) যাতে কনট্র্যাক্ট, প্ল্যান, এবং জেনারেটেড টেস্ট এক জায়গায় থাকে। যখন একটি রিফ্যাক্টর আচরণ অনিয়ন্ত্রিতভাবে বদলায়, স্ন্যাপশট এবং রোলব্যাক তুলনা করে দ্রুত ইটারেট করা সহজ হয় যতক্ষণ না আপনার উচ্চ-সিগন্যাল সেট স্থিতিশীল থাকে।
ডিফল্ট: এমন একটি ছোট সেট লক্ষ্য করুন যা বাস্তবে একটি বাগ ধরতে পারত।
একটি দ্রুত সীমা যা ভাল কাজ করে হল প্রতি ইউনিট 6–10 টেস্ট। যদি এর চেয়ে বেশি লাগে, সাধারণত মানে আপনার ইউনিট খুব বেশি কাজ করছে বা আপনার কনট্র্যাক্ট অস্পষ্ট।
হ্যাপি-পাথ টেস্টগুলি সাধারণত কেবল আপনার উদাহরণ এখনও কাজ করছে তা প্রমাণ করে। এগুলো প্রোডাকশনে যা ভাঙে সেগুলো মিস করে।
উচ্চ-সিগন্যাল টেস্ট লক্ষ্য করে:
একটি টিনি কনট্র্যাক্ট দিয়ে শুরু করুন যা এক শ্বাসে পড়া যায়:
তারপর সেই কনট্র্যাক্ট থেকে টেস্ট জেনারেট করুন, কেবল উদাহরণ থেকে নয়।
প্রথমে এগুলো টেস্ট করুন:
প্রতি ইনপুট ডাইমেনশনের জন্য ১–২টা বেছে নিন যাতে প্রতিটি টেস্ট একক ঝুঁকি কভার করে।
একটি ভাল failure-mode টেস্ট দুইটি জিনিস প্রমাণ করে:
ডাটাবেস রাইট থাকলে ব্যর্থতার পরে স্টোরেজে কি হল তা অবশ্যই চেক করুন।
ডিফল্ট পদ্ধতি: ইনভারিয়েন্টটিকে পর্যবেক্ষণযোগ্য আউটকামের উপর একটি অ্যাসারশন হিসেবে রূপান্তর করুন।
উদাহরণ:
expect(total).toBeGreaterThanOrEqual(0)রিটার্ন ভ্যালু এবং সাইড-এফেক্ট উভয়ই চেক করতে পছন্দ করুন, কারণ অনেক বাগ লুকায় "OK রিটার্ন করেছে কিন্তু ভুল লিখেছে।"
হ্যাপি-পাথ টেস্ট রাখার জোরালো কারণ রয়েছে যদি এটি কোনো ইনভারিয়েন্ট বা গুরুত্বপূর্ণ ইন্টিগ্রেশনকে রক্ষা করে।
ভাল কারণগুলো:
নাহলে, এটি সীমান্ত/ফেইলিওর টেস্টের জন্য বদলান যা আরও বেশি ক্লাসের বাগ ধরবে।
প্রথমে PHASE 1: কেবল প্ল্যান চাও।
মডেলকে চেয়ুন:
আপনি প্ল্যান অনুমোদন করার পরই কোড জেনারেট করতে বলুন।
ডিফল্ট: কেবল সেই সীমারটুকু মক করুন যা আপনার কন্ট্রোল করেন না (DB/নেটওয়ার্ক/ঘড়ি), এবং বাকিটা বাস্তবে রাখুন।
ওভার-মক থেকে বাঁচতে:
যদি টেস্ট রিফ্যাক্টরের সময় ভাঙে কিন্তু আচরণ বদলায়নি, সেটি প্রায়ই ওভার-মকড বা ইমপ্লিমেন্টেশন-কাপলড।
একটি সহজ ডিলিশন টেস্ট ব্যবহার করুন:
ডুপ্লিকেটগুলোও স্ক্যান করুন: