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

কেন হ্যাপি-পাথ টেস্ট জেনারেশন সময় নষ্ট করে\n\nঅটোমেটেড টেস্ট স্যুটগুলো প্রথমদিকে ইমপ্রেসিভ দেখায়: ডজন ডজন টেস্ট, অনেক সেটআপ কোড, এবং প্রতিটি ফাংশনের নাম কোথাও না কোথাও দেখা যায়। কিন্তু এসবের অনেকটাই কেবল "সব ঠিক থাকলে কাজ করে" ধরনের চেক। এগুলো সহজে পাস করে, দুর্লভভাবে বাগ ধরেছে, এবং পড়া ও রক্ষণাবেক্ষণ করতে সময় খায়।\n\nএকটি সাধারণ Claude Code টেস্ট জেনারেশন প্রম্পটে মডেলটি প্রায়শই দেখানো উদাহরণ ইনপুটগুলোর অনুকরণ করে। আপনি দেখতে পাবেন ভিন্ন ভিন্ন ভ্যারিয়েশন কিন্তু একই আচরণই কভার করে। ফলাফল হিসেবে বড় স্যুট কিন্তু পাতলা কভারেজ যেখানে প্রকৃতপক্ষে দরকার।\n\nউচ্চ-সিগন্যাল টেস্টগুলো আলাদা। এগুলোই ছোট সেট যা গত মাসের ইনসিডেন্ট ধরত। যখন আচরণ ঝুঁকিপূর্ণভাবে বদলে যায়, এগুলো ফেল করে, এবং হালকা রিফ্যাক্টরের সময় স্থিতিশীল থাকে। একটি উচ্চ-সিগন্যাল টেস্ট কবে কখনো বিশটি “প্রত্যাশিত মান রিটার্ন করে” চেকের চেয়ে মূল্যবান হতে পারে।\n\nকম-মূল্য হ্যাপি-পাথ জেনারেশনের সাধারণ লক্ষণগুলো:\n\n- অনেক টেস্ট কেবল ইনপুট লেবেলে আলাদা, কিন্তু যা ভেঙে যেতে পারে তা একরকম।\n- অ্যাসারশনগুলো পাথাল ("নাল না", "স্ট্যাটাস 200") এর চেয়ে মানে পরীক্ষা করে না।\n- সেটআপ আচরণটির চেয়ে ভারী, ফলে মানুষ টেস্ট আপডেট করা বন্ধ করে দেয়।\n- কভারেজ উচ্চ দেখালেও এজ-কেস অটেনশন পায় না।\n\nভাবুন একটি ফাংশন আছে যা ডিসকাউন্ট কোড প্রয়োগ করে। হ্যাপি-পাথ টেস্টগুলো নিশ্চিত করে যে "SAVE10" দাম কমায়। প্রকৃত বাগগুলো অন্য জায়গায় লুকানো থাকে: 0 বা নেগেটিভ প্রাইস, এক্সপায়ারড কোড, রাউন্ডিং এজ, অথবা সর্বোচ্চ ডিসকাউন্ট ক্যাপ। এগুলোই খারাপ টোটাল, রাগী কাস্টমার, এবং মধ্যরাত্রির রোলব্যাক ঘটায়।\n\nলক্ষ্য হওয়া উচিত "আরো টেস্ট" থেকে "ভাল টেস্ট" এ জাওয়া—এটি তিনটি টার্গেটের দিকে লক্ষ্য রাখে: সীমান্ত, ব্যর্থতা মোড, এবং ইনভারিয়েন্ট।\n\n## তিনটি লক্ষ্য: সীমান্ত, ব্যর্থতা মোড, ইনভারিয়েন্ট\n\nযদি আপনি উচ্চ-সিগন্যাল ইউনিট টেস্ট চান, "আরো টেস্ট" চাওয়া বন্ধ করুন এবং তিনটি নির্দিষ্ট ধরনের টেস্ট চাওয়া শুরু করুন। এটি Claude Code টেস্ট জেনারেশন প্রম্পটের মূল: কাজের কভারেজ দেয়ার বদলে ব্যবহারিক কভারেজ উৎপন্ন করা।\n\n### 1) সীমান্ত (যেখানে বাগ লুকায়)\n\nসীমান্তগুলো কোড যে ইনপুট বা আউটপুট গৃহীত করে তার কিনারাগুলি। অনেক বাস্তব ত্রুটি থাকে অফ-বাই-ওয়ান, খালি-স্টেট, বা টাইমআউট সমস্যা যা হ্যাপি-পাথ এ আসে না।\n\nনূন্যতম ও সর্বোচ্চ (0, 1, সর্বোচ্চ দৈর্ঘ্য), খালি বনাম উপস্থিত ("", [], nil), অফ-বাই-ওয়ান (n-1, n, n+1), এবং সময়সীমা (কাটঅফের কাছাকাছি) এ ভাবুন।\n\nউদাহরণ: যদি একটি API “শুধু পর্যন্ত 100 আইটেম” নেয়, 3 নয়—100 এবং 101 টেস্ট করুন।\n\n### 2) ব্যর্থতা মোড (নিরাপদভাবে ব্যর্থ হয় কিনা প্রমাণ করুন)\n\nব্যর্থতা মোড হলো সিস্টেম কিভাবে ভেঙে যেতে পারে: খারাপ ইনপুট, অনুপস্থিত ডিপেন্ডেন্সি, আংশিক রেজাল্ট, বা আপস্ট্রিম ত্রুটি। ভাল ব্যর্থতা মোড টেস্ট স্ট্রেসে আচরণ যাচাই করে, কেবল আদর্শ পরিস্থিতির আউটপুট নয়।\n\nউদাহরণ: যখন একটি ডাটাবেস কল ফেল করে, ফাংশনটি কি একটি স্পষ্ট এরর রিটার্ন করে এবং আংশিক ডেটা লেখার থেকে বিরত থাকে?\n\n### 3) ইনভারিয়েন্ট (নিয়ম যে সবসময় সত্য থাকা উচিত)\n\nইনভারিয়েন্টগুলো হল এমন সত্য যা কলের আগে এবং পরে একইভাবে থাকতে হবে। এগুলো অস্পষ্ট সঠিকতাকে পরিষ্কার অ্যাসারশনে পরিণত করে।\n\nউদাহরণ:\n\n- "ব্যালান্স কখনও নেগেটিভ হয় না" কোনো উত্তোলনের পরে।\n- "IDs ইউনিক" এমনকি দ্রুত আইটেম তৈরি করলেও।\n- "এরর হলে কোনো স্টেট পরিবর্তন নয়" (কোন নতুন রো, কোন ফ্ল্যাগ পাল্টে না)।\n\nএই তিনটি লক্ষ্য পেলে, টেস্টগুলো কম হবে, কিন্তু প্রতিটি টেস্টে বেশি সিগন্যাল থাকবে।\n\n## প্রস্তুতি: টেস্ট লেখার আগে একটি ছোট কনট্র্যাক্ট বের করুন\n\nযদি আপনি অনেক আগেই টেস্ট চেয়ে ফেলেন, সাধারণত একটি ভদ্র "কাজ করছে" চেকের গাদা পাবেন। একটি সহজ সমাধান হল আগে একটি ছোট কনট্র্যাক্ট লিখে নেয়া, তারপর সেই কনট্র্যাক্ট থেকে টেস্ট জেনারেট করা। এটি Claude Code টেস্ট জেনারেশন প্রম্পটকে বাস্তব বাগ খোঁজার যন্ত্রে দ্রুত পরিণত করে।\n\nএকটি দরকারী কনট্র্যাক্ট একশ্বাসেই পড়ার মতো ছোট হওয়া উচিত। 5 থেকে 10 লাইন লক্ষ্য করুন যা তিনটি প্রশ্নের উত্তর দেয়: কি ইনপুট যায়, কি আউটপুট আসে, এবং আরও কি পরিবর্তন হয়।\n\n### 5–10 লাইন কনট্র্যাক্ট টেমপ্লেট\n\nকনট্র্যাক্ট সোজা ভাষায় লিখুন, কোড নয়, এবং শুধু যা টেস্ট করা যায় তা রাখুন।\n\n- ইনপুট: টাইপ, অনুমোদিত রেঞ্জ, এবং কি খালি বা মিসিং গণ্য হবে।\n- আউটপুট: রিটার্ন ভ্যালু বা এরর আকার, এবং "সাফল্য" কী গ্যারান্টি দেয়।\n- সাইড-এফেক্ট: স্টেট, ডাটাবেস রো, নেটওয়ার্ক কল, ফাইল, লগে কি পরিবর্তন হয়।\n- অনুমান: কলাররা প্রায় ভুল করে এমন জিনিস (টাইমজোন, এনকোডিং, অথ, অর্ডারিং)।\n- "কখনো হবে না": ক্র্যাশ, নিঃশব্দ ডাটা লস, ডাবল চার্জ, আংশিক লেখা।\n\nএকবার এটা হাতে পেলেই, দেখে নিন কোথায় বাস্তবতা আপনার অনুমান ভাঙতে পারে। সেগুলোই সীমান্ত কেস (min/max, শূন্য, ওভারফ্লো, খালি স্ট্রিং, ডুপ্লিকেট) এবং ব্যর্থতা মোড (টাইমআউট, পারমিশন ডিনাই, ইউনিক কনস্ট্রেন্ট ব্যর্থতা, করাপ্টেড ইনপুট) হয়ে ওঠে।\n\nনিচে 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 টেস্ট। যদি এর চেয়ে বেশি লাগে, সাধারণত মানে আপনার ইউনিট খুব বেশি কাজ করছে বা আপনার কনট্র্যাক্ট অস্পষ্ট।
অনেকগুলি হ্যাপি-পাথ টেস্ট জেনারেট করায় কী সমস্যা?
হ্যাপি-পাথ টেস্টগুলি সাধারণত কেবল আপনার উদাহরণ এখনও কাজ করছে তা প্রমাণ করে। এগুলো প্রোডাকশনে যা ভাঙে সেগুলো মিস করে।
উচ্চ-সিগন্যাল টেস্ট লক্ষ্য করে:
- সীমান্ত (0/1/ম্যাক্স, খালি/null, অফ-বাই-ওয়ান)
- ব্যর্থতা মোড (টাইমআউট, অবৈধ ইনপুট, ডিপেন্ডেন্সি এরর)
- ইনভারিয়েন্ট (যে নিয়মগুলো সবসময় মানতে হবে, যেমন “এরর হলে আংশিক লেখা হবে না”)
AI-কে টেস্ট জেনারেট করতে বলার আগে আমাকে কী লিখে রাখতে হবে?
একটি টিনি কনট্র্যাক্ট দিয়ে শুরু করুন যা এক শ্বাসে পড়া যায়:
- ইনপুট: টাইপ, অনুমোদিত রেঞ্জ, কি খালি/মিসিং গণ্য হবে
- আউটপুট: সফল আকার এবং এরর আকার
- সাইড-এফেক্ট: কী লেখা/পরিবর্তিত হতে পারে (DB, ফাইল, নেটওয়ার্ক)
- “কখনই ঘটবে না”: ক্র্যাশ, নিঃশব্দ ডাটা লস, ডাবল চার্জ, আংশিক লেখা
তারপর সেই কনট্র্যাক্ট থেকে টেস্ট জেনারেট করুন, কেবল উদাহরণ থেকে নয়।
কোন সীমানা কেসগুলো সাধারণত টেস্ট করা উচিত?
প্রথমে এগুলো টেস্ট করুন:
- মিন/ম্যাক্স মান (0, 1, max, max+1)
- খালি বনাম উপস্থিত ("", [], null)
- অফ-বাই-ওয়ান (n-1, n, n+1)
- ফরম্যাটিং এজ (হোয়াইটস্পেস-চলক, লিডিং জিরো)
- টাইম কাটঅফ (একটু আগে/পরে এক্সপায়ারি)
প্রতি ইনপুট ডাইমেনশনের জন্য ১–২টা বেছে নিন যাতে প্রতিটি টেস্ট একক ঝুঁকি কভার করে।
আমি কীভাবে একটি শ্যালো টেস্টের বদলে একটি ভাল "failure mode" টেস্ট লিখি?
একটি ভাল failure-mode টেস্ট দুইটি জিনিস প্রমাণ করে:
- ফাংশনটি স্পষ্ট, প্রত্যাশিত এরর রিটার্ন করে (টাইপ/মেসেজ/স্ট্যাটাস)।
- এটি নিরাপদভাবে ব্যর্থ করে:
- কোনো আংশিক স্টেট পরিবর্তন নেই
- কোনো অভ্যন্তরীণ ডিটেইল লিক নেই
- অনাবশ্যক রিট্রাই বা সাইড-এফেক্ট নেই
ডাটাবেস রাইট থাকলে ব্যর্থতার পরে স্টোরেজে কি হল তা অবশ্যই চেক করুন।
কীভাবে আমি একটি ইনভারিয়েন্টকে টেস্ট অ্যাসারশনে বদলাই?
ডিফল্ট পদ্ধতি: ইনভারিয়েন্টটিকে পর্যবেক্ষণযোগ্য আউটকামের উপর একটি অ্যাসারশন হিসেবে রূপান্তর করুন।
উদাহরণ:
- “টোটাল কখনও নেগেটিভ হবে না” →
expect(total).toBeGreaterThanOrEqual(0) - “এরর হলে কোনো স্টেট পরিবর্তন নেই” → কোন নতুন রো নেই / কোন ফ্ল্যাগ পরিবর্তিত নেই
- “ইডেমপোটেন্ট” → দুইবার কল করুন এবং নিশ্চিত করুন দ্বিতীয় কল স্টেট পরিবর্তন করে না
রিটার্ন ভ্যালু এবং সাইড-এফেক্ট উভয়ই চেক করতে পছন্দ করুন, কারণ অনেক বাগ লুকায় "OK রিটার্ন করেছে কিন্তু ভুল লিখেছে।"
কখন হ্যাপি-পাথ টেস্ট রাখা ঠিক?
হ্যাপি-পাথ টেস্ট রাখার জোরালো কারণ রয়েছে যদি এটি কোনো ইনভারিয়েন্ট বা গুরুত্বপূর্ণ ইন্টিগ্রেশনকে রক্ষা করে।
ভাল কারণগুলো:
- এটি কনট্র্যাক্ট-লক করে যা কলাররা নির্ভর করে (উদা., রাউন্ডিং নিয়ম)
- এটি অতীত ইন্সিডেন্ট রিগ্রেশন প্রতিরোধ করে
নাহলে, এটি সীমান্ত/ফেইলিওর টেস্টের জন্য বদলান যা আরও বেশি ক্লাসের বাগ ধরবে।
কোড জেনারেট করার আগে আমাকে মডেলকে কী আউটপুট দিতে বলব?
প্রথমে PHASE 1: কেবল প্ল্যান চাও।
মডেলকে চেয়ুন:
- সর্বোচ্চ 6–10টি প্রস্তাবিত টেস্ট
- প্রতিটির জন্য: উদ্দেশ্য, সেটআপ, ইনপুট, প্রত্যাশিত ফলাফল, কেন এটি উচ্চ-সিগন্যাল
- একটি ছোট বাউন্ডারি ম্যাট্রিক্স
- একটি ফেইলিওর-মোড তালিকা
- 3–5টি ইনভারিয়েন্ট এবং কিভাবে অ্যাসার্ট করা হবে
আপনি প্ল্যান অনুমোদন করার পরই কোড জেনারেট করতে বলুন।
কীভাবে টেস্টগুলো এত ব্রিটল হবেন না যাতে সবকিছু মক করা থাকে?
ডিফল্ট: কেবল সেই সীমারটুকু মক করুন যা আপনার কন্ট্রোল করেন না (DB/নেটওয়ার্ক/ঘড়ি), এবং বাকিটা বাস্তবে রাখুন।
ওভার-মক থেকে বাঁচতে:
- কেবল ইন্টারনাল হেল্পার মক করবেন না যেন ইমপ্লিমেন্টেশন মিরর করা হয়
- সম্ভব হলে ইন-মেমরি বা ছোট ফেইক ব্যবহার করুন
- ঘড়ি/র্যান্ডমনেস মক করুন যদি তা অ্যাসারশনে প্রভাব ফেলে
যদি টেস্ট রিফ্যাক্টরের সময় ভাঙে কিন্তু আচরণ বদলায়নি, সেটি প্রায়ই ওভার-মকড বা ইমপ্লিমেন্টেশন-কাপলড।
আমি কী দ্রুত বলতে পারি একটি AI-জেনারেটেড টেস্ট কম-মূল্য?
একটি সহজ ডিলিশন টেস্ট ব্যবহার করুন:
- যদি আপনি ওই টেস্টটি মুছে ফেলেন এবং কোন সীমা, কোন ফেইলিওর মোড, বা কোন ইনভারিয়েন্ট না হারান, তাহলে সেটি থাকার যোগ্য ছিল না।
ডুপ্লিকেটগুলোও স্ক্যান করুন:
- যদি দুইটা টেস্ট একই বাগের জন্য ফেল করে, শক্তিশালী অ্যাসারশনের টেস্ট রাখুন
- যদি অ্যাসারশন শুধুই “not null” বা “status 200” হয়, শক্ত করুন বা টেস্ট বাদ দিন