ফুল-স্ট্যাক test কৌশল — pyramid, trophy আর কী test করবেন

১ · Test কেন — refactor-এর সাহস আর deploy-এর ভরসা

বৃহস্পতিবার রাত। কাল থেকে বাজারঘরে ঈদের অফার শুরু। নতুন কুপন EID10: ১০% ছাড়, সর্বোচ্চ ২০০ টাকা। ডেভেলপার রাফি দামের হিসাবের function-এ তিন লাইন বদলালেন। এখন প্রশ্ন দুটি। এক, আগের নিয়মগুলো কি এখনো ঠিক আছে? ১০০০ টাকা বা তার বেশি কেনাকাটায় ফ্রি ডেলিভারি, স্টক না থাকলে অর্ডার বন্ধ, অন্যের অর্ডার দেখা যায় না। দুই, এই কোড কি রাতেই production-এ পাঠানো যায়?

Test ছাড়া দুটি প্রশ্নের উত্তর একটাই: “মনে হয় ঠিক আছে।” হাতে ক্লিক করে পাঁচটি পাতা দেখা যায়, পঞ্চাশটি নিয়ম দেখা যায় না। স্বয়ংক্রিয় test এখানে দুটি জিনিস দেয়।

• Refactor-এর সাহস। Refactoring মানে বাইরের আচরণ না বদলে ভেতরের গঠন বদলানো। কিন্তু আচরণ সত্যিই বদলায়নি, তা জানবেন কীভাবে? পর্ব ২৯-এ service-কে নকল repository দিয়ে test করেছিলেন, যাতে database বদলালেও নিয়মগুলো পাহারায় থাকে। ভালো test থাকলে কোড পরিষ্কার করা ভয়ের কাজ থাকে না।
• Deploy-এর ভরসা। প্রতিটি বদলের পরে একই পরীক্ষা যন্ত্র নিজে চালায়, মানুষ ক্লান্ত হলেও। পুরোনো ঠিক জিনিস নতুন বদলে ভেঙে যাওয়াকে বলে regression. Regression ধরাই test-এর প্রতিদিনের কাজ। এই test-গুলো প্রতিটি push-এ চালানোর pipeline আসবে পর্ব ৮১-এ।

একটি সীমাও শুরুতেই মনে রাখুন। Edsger Dijkstra-র বহুল উদ্ধৃত কথা (১৯৬৯-৭০ সালের দিকের লেখা ও বক্তৃতায়): test বাগের উপস্থিতি দেখাতে পারে, অনুপস্থিতি কখনো নয়। সবুজ test মানে “যা যাচাই করেছি, তাতে ভুল পাইনি।” কী যাচাই করবেন, সেটি বাছাই করাই এই পর্বের বিষয়। Test-এর মৌলিক তত্ত্ব আছে Software Engineering কোর্সের testing fundamentals পর্বে; এখানে সেটি আবার পড়াব না।

বাজারঘরের একটি অনুরোধ কয়েকটি অংশ পার হয়: browser, React component, Express API, database, আর মাঝখানে দামের হিসাবের মতো খাঁটি logic. প্রতিটি ধরনের test এদের কোনটি আসলে চালায়, নিচের ছকে দেখুন। ছকের সময়গুলো আমার ল্যাবের একটি local run, সাধারণ ফল নয়।

২ · ফুল-স্ট্যাকের চার স্তর — কোন test আসলে কী চালায়

নাম নিয়ে বিভ্রান্তি খুব বেশি। এক দলের “integration test” আরেক দলের “API test”. তাই নামের চেয়ে প্রশ্নটি জরুরি: এই test-এ কোন অংশ আসল, কোন অংশ নকল? বাজারঘরে চারটি স্তর এভাবে ভাগ করব, আর তার নিচে একটি পঞ্চম ভিত্তি।

মাঝের দুটি স্তরকে অনেকে একসাথে integration test বলেন: কয়েকটি আসল অংশ একসাথে চালানো test. Static স্তরে test লিখতে হয় না, কিন্তু সে বিনা খরচে একদল ভুল আগেই ধরে। এর ব্যবস্থা পর্ব ৫-এ (ESLint) আর পর্ব ৬-এ (TypeScript) দেখেছেন। একে বলে static analysis.

এখন দেখা যাক একটি test runner আসলে কী করে। Vitest এই পাতায় চলে না, তাই নিচে ২০ লাইনের একটি শেখার মডেল। এটি Vitest নয়, শুধু তার মূল ধারণা: test একটি নাম আর একটি function নেয়, চালায়, আর ব্যতিক্রম ছুড়লে ফেল ধরে। expect একটি assertion বানায়।

// Teaching model of a test runner. Not Vitest, only the idea.
const results = [];
function test(name, fn) {
  try { fn(); results.push(['PASS', name]); }
  catch (e) { results.push(['FAIL', name + ' -> ' + e.message]); }
}
function expect(actual) {
  return { toBe(want) {
    if (!Object.is(actual, want)) throw new Error(`expected ${want}, got ${actual}`);
  } };
}
// Code under test: paisa in, paisa out (100 paisa = 1 taka).
function calcTotal(items, coupon) {
  const subtotal = items.reduce((s, it) => s + it.pricePaisa * it.qty, 0);
  const discount = coupon === 'EID10' ? Math.min(Math.round(subtotal * 0.1), 20000) : 0;
  const delivery = subtotal - discount >= 100000 ? 0 : 6000;
  return subtotal - discount + delivery;
}
const rice = { pricePaisa: 45000, qty: 2 };
const dal = { pricePaisa: 15000, qty: 1 };
test('below 1000 taka pays 60 taka delivery', () => expect(calcTotal([dal])).toBe(21000));
test('1050 taka cart has free delivery', () => expect(calcTotal([rice, dal])).toBe(105000));
test('EID10 can bring delivery back', () => expect(calcTotal([rice, dal], 'EID10')).toBe(100500));
test('discount is capped at 200 taka', () =>
  expect(calcTotal([{ pricePaisa: 500000, qty: 1 }], 'EID10')).toBe(480000));
test('a wrong expectation fails loudly', () => expect(calcTotal([dal])).toBe(15000));

for (const [status, name] of results) console.log(status, name);
const failed = results.filter((r) => r[0] === 'FAIL').length;
console.log(`Tests: ${results.length - failed} passed, ${failed} failed`);

দামগুলো পয়সায়, পূর্ণসংখ্যায়, যেমন পর্ব ৪৩-এ দেখেছেন। Vitest-এর describe, it, expect একই আকারের, শুধু অনেক বেশি সুবিধাসহ: watch mode, mock, snapshot, coverage. সেগুলো আসবে পর্ব ৭৩-এ।

৩ · Pyramid, trophy আর honeycomb — একই প্রশ্নের তিন উত্তর

কোন স্তরে কতগুলো test রাখবেন, তার তিনটি পরিচিত ছবি আছে। বিস্তারিত ইতিহাস আর ছবি আছে test pyramid ও integration পর্বের অংশ ৩-এ. এখানে সংক্ষেপে, তারপর ফুল-স্ট্যাকের চোখে।

তিনটি ছবি তিনটি মাপের মধ্যে টানাপোড়েন দেখায়। কোনো স্তর তিনটিতেই জেতে না।

হিসাব করে দেখুন: suite কত সময় নেয়

একটি ধরে নেওয়া suite: ৩০০টি unit test, প্রতিটি গড়ে ২ ms; ৮০টি component test, প্রতিটি ৩০ ms; ৬০টি API test, প্রতিটি ১০ ms; আর ১০টি E2E, প্রতিটি ৩ সেকেন্ড। সংখ্যাগুলো উদাহরণ, মাপা নয়।

• Unit: ৩০০ × ২ = ৬০০ ms
• Component: ৮০ × ৩০ = ২,৪০০ ms
• API: ৬০ × ১০ = ৬০০ ms
• E2E: ১০ × ৩,০০০ = ৩০,০০০ ms
• মোট: ৩৩,৬০০ ms, অর্থাৎ ৩৩.৬ সেকেন্ড। E2E-র ভাগ ৩০,০০০ ÷ ৩৩,৬০০ ≈ ৮৯.৩%, অথচ সংখ্যায় সেগুলো মোট test-এর মাত্র ২%.

E2E চারটি worker-এ ভাগ করে চালালে তাদের অংশ হয় ৭.৫ সেকেন্ড, আর মোট ৩.৬ + ৭.৫ = ১১.১ সেকেন্ড. শিক্ষা দুটি। এক, suite-এর সময় নির্ধারণ করে ধীরতম স্তরের সংখ্যা, মোট test-এর সংখ্যা নয়। দুই, প্রতিটি নতুন E2E test ৩,০০০ ÷ ২ = ১,৫০০টি unit test-এর সমান সময় খায়। তাই E2E-তে শুধু সেই পথ রাখুন, যা নিচের স্তরে কোনোভাবেই ধরা যায় না।

বাজারঘরের জন্য কোন আকার

সৎ উত্তর: একটি আকার নয়। ফুল-স্ট্যাক অ্যাপ আসলে তিন রকম কোডের মিশ্রণ, আর প্রতিটি অংশ নিজের আকার চায়।

• দাম, ছাড়, VAT, স্টক গোনা: খাঁটি নিয়ম, অনেক কিনারা। এখানে pyramid-এর মতো অনেক unit test.
• React UI: খুঁটিনাটির unit test refactor-এ ভাঙে। এখানে trophy-র মতো component test, যা কয়েকটি component একসাথে চালায়।
• Express API আর database: ভুল থাকে SQL, transaction আর অনুমতিতে। এখানে honeycomb-এর মতো API test, আসল database-সহ।
• সব মিলিয়ে: অল্প কয়েকটি E2E, শুধু টাকা আর অর্ডারের প্রধান পথে।

৪ · বাজারঘরে কী test করবেন — ঝুঁকির মানচিত্র

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

// Risk = likelihood (1-5) x impact (1-5). The numbers are a team's guess.
const features = [
  ['Order total and coupon', 4, 5],
  ['Stock check on checkout', 3, 5],
  ['Payment webhook', 3, 5],
  ['Seller sees only own orders', 2, 5],
  ['Login and password reset', 2, 4],
  ['Product search filters', 3, 2],
  ['Bangla date on invoice', 2, 2],
  ['Footer link colours', 2, 1],
];
function layerFor(score) {
  if (score >= 15) return 'many unit + API tests, one E2E path';
  if (score >= 8) return 'API or component tests';
  if (score >= 4) return 'one test at the cheapest layer';
  return 'no automated test, look at it';
}
const rows = features
  .map(([name, likely, impact]) => ({ name, likely, impact, score: likely * impact }))
  .sort((a, b) => b.score - a.score);
console.log('feature'.padEnd(28), 'L', 'I', 'score', ' suggested');
let all = 0;
for (const r of rows) {
  console.log(r.name.padEnd(28), r.likely, r.impact, String(r.score).padStart(5), '', layerFor(r.score));
  all += r.score;
}
const top3 = rows.slice(0, 3).reduce((s, r) => s + r.score, 0);
console.log(`top 3 of ${rows.length} features carry ${Math.round((top3 / all) * 100)}% of the risk`);

এবার মানচিত্রটি স্তরসহ। প্রতিটি সারিতে প্রশ্ন একটাই: এই ভুলটি সবচেয়ে সস্তায় কোন স্তরে ধরা যায়?

কী test করবেন না, সেটিও সিদ্ধান্ত। React নিজে ঠিক কাজ করে কি না, Prisma সারি লেখে কি না, এসব তাদের নিজেদের দলের কাজ। Private helper-এর আলাদা test সাধারণত লাগে না; বাইরের আচরণের test সেগুলো এমনিই চালায়। বাইরের payment gateway-কে প্রতিটি test-এ সত্যি ডাকবেন না; পর্ব ৬৫-এর নকল gateway-ই যথেষ্ট। আর pixel-এর মাপ test-এ বাঁধলে প্রতিটি design বদলে test লাল হবে, অথচ ক্রেতার কোনো ক্ষতি হয়নি।

একটি feature হাতে এলে স্তর বাছাইয়ের চিন্তা ধাপে ধাপে দেখুন। প্রতিটি ধাপে একটি নতুন feature, আর সবচেয়ে সস্তা যে স্তর ভুলটি ধরতে পারে, সেটি উজ্জ্বল হবে।

৫০০০ টাকার কার্ট, কুপন EID10
১০% = ৫০০ টাকা → সীমা ২০০ টাকা
calcTotal(items, 'EID10').discount === 20000

ক্রেতা "eid10" লিখলেন → মোট ৳1,005
"অর্ডার করুন" চাপলেন
onOrder 100500 দিয়ে ডাকা হলো কি?

ডাল স্টকে ১টি, অর্ডারে চাল ১ + ডাল ২
প্রত্যাশা: 409, চালের স্টকও আগের মতো ১০
(প্রথম লাইন rollback হয়েছে)

পাতা খোলা → চাল কার্টে → অর্ডার করুন
পাতায় দেখা যায়: অর্ডার নিশ্চিত, মোট ৳510

body: { productId: 2, qty: 1, pricePaisa: 1 }
প্রত্যাশা: দাম database থেকে, মোট 21000

API পাঠায় pricePaisa: "45000" (string)
React-এ "45000" + 6000 → "450006000"
ভাগ করা type থাকলে compile-এই ধরা পড়ে

ঝুঁকি = ২ × ১ = ২
ভুল হলে: দেখতে খারাপ, ক্ষতি নেই
test লিখলে: প্রতিটি design বদলে লাল

৫ · আচরণ test করুন, implementation-এর খুঁটিনাটি নয়

Testing Library-র মূল নীতিটি Kent C. Dodds এভাবে বলেন: test যত বেশি আপনার software-এর আসল ব্যবহারের মতো হবে, তত বেশি আস্থা দেবে। উল্টো দিকটি হলো implementation detail: class-এর নাম, ভেতরের state, কোন helper কতবার ডাকা হলো। ব্যবহারকারী এগুলো দেখেন না। এসব ধরে লেখা test হয় brittle test: আচরণ না বদলালেও ভাঙে।

ভঙ্গুর test-এর দুটি দোষ। এক, নির্দোষ refactor-এ লাল হয়ে মিথ্যা alarm দেয়। দুই, যা আসলে জরুরি তা যাচাই করে না, তাই আসল বাগ সবুজ রঙেই পার হয়ে যায়। নিচে একই কার্টের তিনটি বাস্তবায়ন: v1, তার নির্দোষ refactor v2, আর একটি সত্যিকারের বাগসহ v3.

// Three implementations of the same cart summary.
function summaryV1(items) {
  const lines = items.map((it) => it.pricePaisa * it.qty);
  const total = lines.reduce((a, b) => a + b, 0);
  return { lines, total, text: 'Total: Tk ' + total / 100 };
}
function summaryV2(items) { // harmless refactor: no lines array any more
  let total = 0;
  for (const it of items) total += it.pricePaisa * it.qty;
  return { total, text: 'Total: Tk ' + total / 100 };
}
function summaryV3(items) { // a real bug: the text shows only the first line
  const lines = items.map((it) => it.pricePaisa * it.qty);
  const total = lines.reduce((a, b) => a + b, 0);
  return { lines, total, text: 'Total: Tk ' + lines[0] / 100 };
}
const cart = [{ pricePaisa: 45000, qty: 2 }, { pricePaisa: 15000, qty: 1 }];
// Brittle: reaches into an internal field that exists only by accident.
const brittle = (s) => s.lines.length === 2 && s.lines[0] === 90000;
// Behaviour: checks only what the shopper reads.
const behaviour = (s) => s.text === 'Total: Tk 1050';

for (const [name, impl] of [['v1', summaryV1], ['v2', summaryV2], ['v3', summaryV3]]) {
  for (const [kind, check] of [['brittle', brittle], ['behaviour', behaviour]]) {
    let verdict;
    try { verdict = check(impl(cart)) ? 'PASS' : 'FAIL'; }
    catch (e) { verdict = `FAIL (${e.constructor.name}: ${e.message})`; }
    console.log(name, kind.padEnd(9), verdict);
  }
}

আসল React component-এ একই ঘটনা

এবার ল্যাবে আসল জিনিস: React 19.3.1-এর CartSummary, Vitest 5.1.0, Testing Library 16.3.3 আর jsdom 30.1.3. প্রথম test-টি markup চেনে:

// Brittle: it knows the class names and the order of the spans.
it('total cell shows 1,050', () => {
  const { container } = render(<CartSummary items={items} onOrder={() => {}} />);
  const cell = container.querySelector('.row.total span:last-child');
  expect(cell.textContent).toBe('৳1,050');
  expect(container.querySelectorAll('.row')).toHaveLength(2);
});

দ্বিতীয় test ক্রেতার চোখে দেখে: পাতার লেখা, label দিয়ে খোঁজা input, আর role ও নাম দিয়ে খোঁজা বোতাম।

it('a coupon changes the total the order is placed with', async () => {
  const user = userEvent.setup();
  const onOrder = vi.fn();
  render(<CartSummary items={items} onOrder={onOrder} />);
  await user.type(screen.getByLabelText('কুপন'), 'eid10');
  await user.click(screen.getByRole('button', { name: 'অর্ডার করুন' }));
  expect(onOrder).toHaveBeenCalledWith(100500);
});

তারপর একটি নির্দোষ refactor: div আর span-এর বদলে dl, dt, dd, আর পুরোনো class-এর বদলে Tailwind-এর class (পর্ব ২২)। ক্রেতার চোখে পাতা হুবহু একই। নিচের stepper-এ সত্যিকারের run ধরে এগিয়ে দেখুন।

<div className="row total">
  <span>মোট</span><span>{formatTaka(t.total)}</span>
</div>

 ✓ tests/brittle/cart.brittle.test.jsx > total cell shows 1,050 32ms
 ✓ ... > shows the total and free delivery 24ms
 ✓ ... > a coupon changes the total the order is placed with 228ms
 ✓ ... > an empty cart cannot be ordered 4ms
      Tests  4 passed (4)

<dl className="grid grid-cols-2 gap-1">
  <dt className="font-bold">মোট</dt>
  <dd className="font-bold">{formatTaka(t.total)}</dd>
</dl>

 × tests/brittle/cart.brittle.test.jsx > total cell shows 1,050 32ms
   → Cannot read properties of null (reading 'textContent')
 ❯ tests/brittle/cart.brittle.test.jsx:13:15
     13|   expect(cell.textContent).toBe('৳1,050');

 ✓ ... > shows the total and free delivery 25ms
 ✓ ... > a coupon changes the total the order is placed with 200ms
 ✓ ... > an empty cart cannot be ordered 5ms
      Tests  1 failed | 3 passed (4)

onClick={() => onOrder(t.subtotal)}   // should be t.total

 × a coupon changes the total the order is placed with 253ms
AssertionError: expected "vi.fn()" to be called with arguments: [ 100500 ]
-   100500,
+   105000,
 Test Files  1 failed | 1 passed (2)

তাহলে implementation-এর test কি সবসময় নিষেধ? না। কিছু “ভেতরের” বিষয় আসলে চুক্তি। পর্ব ৪২-এর query budget test গোনে একটি পাতায় কতগুলো SQL চলল; এটি implementation, কিন্তু performance-এর চুক্তি, তাই ইচ্ছা করেই বাঁধা। নিয়ম হলো: যা ভাঙলে ব্যবহারকারী বা অন্য দল ক্ষতিগ্রস্ত হন, সেটি test করুন; যা বদলালে কারও কিছু যায় আসে না, সেটি test-এ বাঁধবেন না।

৬ · এক project, চার স্তর — সত্যিকারের run আর সময়

সব কথার প্রমাণ হিসেবে একটি ছোট project বানিয়েছি, যেখানে প্রতিটি স্তরে কয়েকটি test আছে। লেখার সময়ের version: Node.js 24.15.0, Vitest 5.1.0 আর @vitest/coverage-v8 5.1.0, React 19.3.1, @testing-library/react 16.3.3, @testing-library/user-event 14.6.8, @testing-library/jest-dom 7.0.1, jsdom 30.1.3, Express 5.3.0, supertest 7.3.1, @playwright/test 1.64.1 (Microsoft Edge-এ), আর Stryker 10.1.1. Database হিসেবে Node-এর নিজস্ব node:sqlite-এর in-memory database, যাতে প্রতিটি test নতুন, খালি database পায়। আসল PostgreSQL-এ test database বানানো আসবে পর্ব ৭৫-এ।

~/bazarghar
├── src/price.js            calcTotal, formatTaka
├── src/CartSummary.jsx     React component
├── src/app.js              Express API + node:sqlite
├── public/index.html       a tiny shop page for E2E
├── tests/unit/price.test.js
├── tests/component/cart.behaviour.test.jsx
├── tests/api/orders.test.js
├── e2e/checkout.spec.js
├── vitest.config.js
└── playwright.config.js

API স্তরের একটি test পুরোটা দেখুন। এখানে আসল Express route, আসল SQL আর আসল transaction চলে; শুধু network-এর বদলে supertest app-কে সরাসরি ডাকে।

beforeEach(() => {
  db = openDb();          // a fresh in-memory database for every test
  app = makeApp(db);
});

it('refuses more than the stock and changes nothing', async () => {
  const res = await request(app).post('/api/orders').set(auth)
    .send({ items: [{ productId: 1, qty: 1 }, { productId: 2, qty: 2 }] });
  expect(res.status).toBe(409);
  expect(stockOf(1)).toBe(10);   // the first line was rolled back
  expect(stockOf(2)).toBe(1);
});

আর একমাত্র E2E test, যা Playwright নিজেই server চালু করে, Edge খোলে, ক্লিক করে, শেষে server বন্ধ করে:

test('a shopper adds rice and places an order', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('button', { name: 'Chinigura rice 5kg কার্টে যোগ করুন' }).click();
  await page.getByRole('button', { name: 'অর্ডার করুন' }).click();
  await expect(page.getByRole('status')).toHaveText('অর্ডার নিশ্চিত, মোট ৳510');
});

প্রথমে Vitest-এর তিন স্তর একসাথে, সত্যিকারের run:

~/bazarghar$ npx vitest run --reporter=verbose
 RUN  v5.1.0 ~/bazarghar
 ✓ tests/unit/price.test.js > calcTotal > returns all zeros for an empty cart 1ms
 ✓ tests/unit/price.test.js > calcTotal > charges 60 taka delivery below 1000 taka 0ms
 ✓ tests/unit/price.test.js > calcTotal > gives free delivery above 1000 taka 0ms
 ✓ tests/unit/price.test.js > calcTotal > EID10 can push a cart back under the free-delivery line 0ms
 ✓ tests/unit/price.test.js > formatTaka > formats paisa as taka with Indian grouping 11ms
 ✓ tests/api/orders.test.js > POST /api/orders > creates the order and takes the stock 26ms
 ✓ tests/api/orders.test.js > POST /api/orders > refuses more than the stock and changes nothing 4ms
 ✓ tests/api/orders.test.js > POST /api/orders > ignores a price sent by the client 3ms
 ✓ tests/api/orders.test.js > POST /api/orders > needs a login 3ms
 ✓ tests/component/cart.behaviour.test.jsx > CartSummary (what the shopper sees and does) > shows the total and free delivery 25ms
 ✓ tests/component/cart.behaviour.test.jsx > CartSummary (what the shopper sees and does) > a coupon changes the total the order is placed with 216ms
 ✓ tests/component/cart.behaviour.test.jsx > CartSummary (what the shopper sees and does) > an empty cart cannot be ordered 4ms
 Test Files  3 passed (3)
      Tests  12 passed (12)
   Duration  1.06s (environment 42%, tests 22%, setup 20%, import 13%, transform 2%, worker 1%)

তারপর Playwright, সত্যিকারের run:

~/bazarghar$ npx playwright test --reporter=list
Running 1 test using 1 worker

  ok 1 e2e\checkout.spec.js:3:1 › a shopper adds rice and places an order (373ms)

  1 passed (2.9s)

প্রতিটি স্তর আলাদা করে চালিয়ে পাওয়া সময় নিচে। এগুলো আমার ল্যাবের একটি local run; আপনার যন্ত্রে সংখ্যা আলাদা হবে, তবে অনুপাত মোটামুটি এমনই থাকার কথা।

তিনটি জিনিস লক্ষ করুন। এক, unit test এত দ্রুত যে সময়ের বেশিরভাগ যায় runner চালু করতে। দুই, component test-এর ২৩০ ms-এর প্রায় সবটা user.type-এর পাঁচটি অক্ষর এক এক করে টাইপ করায়; Testing Library সত্যিকারের keystroke-এর মতো event পাঠায়। তিন, এখানে API test প্রতি test-এ component test-এর চেয়েও দ্রুত, কারণ database memory-তে। “Integration মানেই ধীর” কথাটি সবসময় সত্য নয়। আর একমাত্র E2E test-টি একাই বাকি বারোটির মোট সময়ের চেয়ে বেশি নিল।

৭ · Test-এর নাম, Arrange-Act-Assert আর ছোট দলের test budget

নাম একটি বাক্য

Test ফেল করলে প্রথমে চোখে পড়ে তার নাম। নামটি পড়েই বোঝা উচিত কোন আচরণ ভাঙল। উপরের run-এ calcTotal > EID10 can push a cart back under the free-delivery line পড়লেই নিয়মটি জানা যায়, কোড না খুলেই।

তিন অংশের আকার

প্রায় প্রতিটি ভালো test তিন ভাগে পড়া যায়, যাকে বলে Arrange-Act-Assert (AAA). Arrange: শুরুর অবস্থা সাজানো। Act: একটিমাত্র কাজ করা। Assert: ফল মিলিয়ে দেখা। ধারণাটি সাধারণত Bill Wake-এর নামে বলা হয় (আনুমানিক ২০০১); BDD-তে একই আকারের নাম Given-When-Then. বিস্তারিত আছে unit testing পর্বের অংশ ২-এ.

it('gives free delivery above 1000 taka', () => {
  // Arrange
  const items = [rice, dal];          // 900 + 150 = 1050 taka
  // Act
  const t = calcTotal(items);
  // Assert
  expect(t.delivery).toBe(0);
  expect(t.total).toBe(105000);
});

একটি test-এ একাধিক Act থাকলে সাধারণত সেটি দুটি test. আর Assert-এ if বা loop দেখলে সন্দেহ করুন: test-এর ভেতরে যুক্তি থাকলে সেই যুক্তিরও test লাগবে।

দুই-তিনজনের দলের test budget

ছোট দলে সময়ই আসল সীমা। নিচের নিয়মগুলো একটি শুরুর বিন্দু, কোনো মান নয়; সংখ্যাগুলো ধরে নেওয়া।

1. ঝুঁকির প্রথম তিন feature-এ বেশি সময়। টাকা, স্টক আর অনুমতির প্রতিটি নিয়মে unit test, আর প্রতিটি route-এ অন্তত একটি API test, যাতে “যা পাওয়ার কথা নয়” ঘরটিও আছে (পর্ব ৪৮-এর ছক)।
2. প্রতিটি বাগের সাথে একটি test. বাগ ঠিক করার আগে এমন test লিখুন যা বাগটি দেখায় আর লাল হয়। এটিই সবচেয়ে কাজের regression test.
3. E2E এক হাতের আঙুলে গোনা। কেনাকাটা, login, আর হয়তো seller-এর পণ্য যোগ। এর বেশি হলে প্রতিটির জন্য কারণ লিখুন।
4. সময়ের সীমা। ধরা যাক, প্রতিটি push-এ পুরো suite পাঁচ মিনিটের মধ্যে। সীমা পার হলে নতুন test নয়, আগে ধীর test সারান।
5. অস্থির test-এর নিয়ম। কোনো কোড না বদলেও কখনো পাস, কখনো ফেল করা test-কে বলে flaky test. এমন test হয় সেদিনই সারান, নয় আলাদা করে রাখুন; কারণ আর সমাধান আসবে পর্ব ৭৭-এ।

৮ · Coverage — Vitest-এর v8 provider আর সংখ্যার সীমা

Code coverage মাপে test চলার সময় কোডের কোন অংশ অন্তত একবার চলেছে। চার রকম সংখ্যা আসে: statement, branch, function আর line. Vitest দুটি provider দেয়। v8 provider JavaScript engine V8-এর নিজস্ব গোনার ব্যবস্থা ব্যবহার করে, কোডে বাড়তি কিছু ঢোকায় না। istanbul provider কোডে গোনার লাইন বসিয়ে (instrument করে) মাপে। তত্ত্ব, যেমন statement বনাম branch আর MC/DC, আছে coverage ও complexity পর্বে.

test: {
  coverage: {
    provider: 'v8',
    include: ['src/**'],
    exclude: ['src/server.js'],
    reporter: [['text', { skipFull: false }]],
  },
},

আমার প্রথম run-এ ১০০% ফাইলগুলো text report-এ দেখায়নি; skipFull: false দেওয়ার পরে দেখাল। সত্যিকারের run:

~/bazarghar$ npx vitest run --coverage
 % Coverage report from v8
-----------------|---------|----------|---------|---------|-------------------
File             | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
-----------------|---------|----------|---------|---------|-------------------
All files        |   92.85 |    92.85 |    90.9 |   92.15 |
 CartSummary.jsx |     100 |      100 |     100 |     100 |
 app.js          |   89.18 |    88.23 |      80 |   88.57 | 27,35,55-56
 price.js        |     100 |      100 |     100 |     100 |
-----------------|---------|----------|---------|---------|-------------------

সংখ্যার চেয়ে কাজের হলো শেষ কলাম। app.js-এর ২৭ নম্বর লাইন GET /api/products; Vitest-এর কোনো test এটি ডাকে না, শুধু E2E ডাকে, আর E2E এই হিসাবে নেই। ৩৫ নম্বর লাইন 422-এর পথ: ভুল ইনপুট পাঠানো test নেই। ৫৫-৫৬ হলো catch-এর ভেতরের ROLLBACK, যা অপ্রত্যাশিত error-এ চলে। Coverage এভাবে বলে কোথায় test নেই. এখন প্রতিটি লাইনের জন্য সিদ্ধান্ত নিন: 422-এর পথে একটি test সস্তা আর কাজের; catch-এর পথ test করতে database-এ ভুল ঘটাতে হবে, তাই হয়তো পর্ব ৭৫-এর মতো আলাদা ব্যবস্থায়।

১০০% covered, তবু ভুল

উল্টো দিকটি আরও জরুরি: coverage বলে না, যা চলেছে তা ঠিক কি না। পরীক্ষাটি করলাম। price.js-এর নিয়ম “১০০০ টাকা বা তার বেশি হলে ফ্রি ডেলিভারি”; আমি ইচ্ছা করে একটি অক্ষর মুছলাম:

- const delivery = afterDiscount >= FREE_DELIVERY_MIN ? 0 : DELIVERY_FEE;
+ const delivery = afterDiscount > FREE_DELIVERY_MIN ? 0 : DELIVERY_FEE;

~/bazarghar$ npx vitest run tests/unit --coverage --coverage.include=src/price.js
 Test Files  1 passed (1)
      Tests  5 passed (5)
----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files |     100 |      100 |     100 |     100 |
 price.js |     100 |      100 |     100 |     100 |
----------|---------|----------|---------|---------|-------------------

সব সবুজ, সব ১০০. অথচ ঠিক ১০০০ টাকার কার্টে ক্রেতা এখন ৬০ টাকা ডেলিভারি দেবেন। দুটি branch-ই চলেছে, ১৫০ টাকার কার্টে একটি আর ১০৫০ টাকার কার্টে অন্যটি, কিন্তু সীমানার মানটি কোনো test দেয়নি। এই কিনারার মান বাছাইয়ের কৌশলকে বলে boundary value analysis, বিস্তারিত test design পর্বের অংশ ৩-এ. একটি test যোগ করলাম:

~/bazarghar$ npx vitest run -c vitest.boundary.config.js
 FAIL  tests/boundary/boundary.test.js > exactly 1000 taka gets free delivery
AssertionError: expected 6000 to be +0 // Object.is equality
- Expected
+ Received
- 0
+ 6000
      Tests  1 failed | 5 passed (6)

তাহলে লক্ষ্য কত?

১০০% coverage লক্ষ্য বানালে দুটি বিপদ। এক, শেষ কয়েক শতাংশ সাধারণত সবচেয়ে দামি: error-এর পথ, ঘটানো কঠিন ঘটনা। দুই, সংখ্যা লক্ষ্য হলে মানুষ সংখ্যা বাড়ায়, মান নয়: assertion ছাড়া test-ও coverage বাড়ায়। অর্থনীতিবিদ Charles Goodhart-এর নামে পরিচিত এই কথাটির সারাংশ: কোনো মাপ লক্ষ্য হয়ে উঠলে সেটি আর ভালো মাপ থাকে না। এর নাম Goodhart's law.

ব্যবহারিক পথ: coverage-কে মেঝে হিসেবে ব্যবহার করুন, ছাদ হিসেবে নয়। ঝুঁকিপূর্ণ ফাইলে, যেমন price.js-এ, Vitest-এর coverage.thresholds দিয়ে উঁচু সীমা রাখুন, যাতে কেউ test মুছলে CI জানায়। নতুন কোডের coverage কমছে কি না দেখুন। আর সবচেয়ে বেশি দেখুন “Uncovered Line” কলাম, শতাংশ নয়।

৯ · Mutation testing — test-এর test

আগের অংশে নিজে হাতে একটি ভুল ঢুকিয়ে দেখলাম test সেটি ধরে কি না। এই কাজটিই স্বয়ংক্রিয়ভাবে করার নাম mutation testing. একটি tool কোডে ছোট ছোট বদল আনে, যেমন >= থেকে >, - থেকে +, true থেকে false. প্রতিটি বদলানো রূপকে বলে mutant. তারপর প্রতিটি mutant-এর ওপর পুরো suite চালায়। কোনো test লাল হলে mutant “killed”; সব সবুজ থাকলে “survived”, অর্থাৎ এমন একটি ভুল আছে যা আপনার test দেখতে পায় না। মোট mutant-এর কত ভাগ মারা গেল, সেটি mutation score.

পুরো ধারণাটি ৩০ লাইনে, শেখার মডেল হিসেবে। একটি দুর্বল suite আর একটি শক্ত suite, একই চারটি mutant-এর বিরুদ্ধে:

// A tiny mutation tester: change one thing, run the tests, see who notices.
const source = `(subtotal, discount) => {
  const after = subtotal - discount;
  const delivery = after >= 100000 ? 0 : 6000;
  return after + delivery;
}`;
const mutants = [
  ['>= to >', source.replace('>=', '>')],
  ['>= to <=', source.replace('>=', '<=')],
  ['- to +', source.replace('subtotal - discount', 'subtotal + discount')],
  ['6000 to 0', source.replace('6000', '0')],
];
const weak = [
  ['dal 150 taka', (f) => f(15000, 0) === 21000],
  ['cart 1050 taka', (f) => f(105000, 0) === 105000],
];
const strong = [...weak,
  ['exactly 1000 taka', (f) => f(100000, 0) === 100000],
  ['EID10 on 1050', (f) => f(105000, 10500) === 100500],
];
const original = new Function('return ' + source)();
for (const [suiteName, suite] of [['weak', weak], ['strong', strong]]) {
  const greenOnOriginal = suite.every(([, t]) => t(original));
  console.log(`--- ${suiteName} suite: ${suite.length} tests, original passes: ${greenOnOriginal}`);
  let killed = 0;
  for (const [name, code] of mutants) {
    const f = new Function('return ' + code)();
    const catchers = suite.filter(([, t]) => !t(f)).map(([n]) => n);
    if (catchers.length) killed++;
    console.log(name.padEnd(9), catchers.length ? 'KILLED by ' + catchers.join(', ') : 'SURVIVED');
  }
  console.log(`score ${killed}/${mutants.length}`);
}

সীমানার mutant-টি কীভাবে বেঁচে যায়, ধাপে ধাপে দেখুন। মানগুলো আসল Stryker run-এর test থেকে নেওয়া।

1mutate: after >= 100000 → after > 1000002test: dal, 150 taka3test: rice + dal, 1050 taka4test: rice + dal with EID105report: Survived6new test: exactly 1000 taka

Stryker দিয়ে সত্যিকারের run

JavaScript-এর জনপ্রিয় mutation tool Stryker. লেখার সময়ে @stryker-mutator/core আর @stryker-mutator/vitest-runner দুটিই 10.1.1, আর runner-এর peer dependency vitest >=2.0.0, তাই Vitest 5.1.0-এর সাথে চলে। পুরো project নয়, শুধু একটি ছোট ফাইলে চালালাম:

{
  "testRunner": "vitest",
  "vitest": { "configFile": "vitest.unit.config.js", "related": false },
  "mutate": ["src/price.js"],
  "reporters": ["clear-text", "progress"],
  "coverageAnalysis": "perTest"
}

~/bazarghar$ npx stryker run
INFO Instrumenter Instrumented 1 source file(s) with 26 mutant(s)
INFO DryRunExecutor Initial test run succeeded. Ran 5 tests in 0 seconds ...
…
[Survived] EqualityOperator
src/price.js:12:20
-     const delivery = afterDiscount >= FREE_DELIVERY_MIN ? 0 : DELIVERY_FEE;
+     const delivery = afterDiscount > FREE_DELIVERY_MIN ? 0 : DELIVERY_FEE;

[Survived] ObjectLiteral
src/price.js:17:54
-     return '৳' + (paisa / 100).toLocaleString('en-IN', { maximumFractionDigits: 2 });
+     return '৳' + (paisa / 100).toLocaleString('en-IN', {});

File      |  total | covered | # killed | # timeout | # survived | # no cov | # errors |
All files |  92.31 |   92.31 |       24 |         0 |          2 |        0 |        0 |
INFO MutationTestExecutor Done in 2 seconds.

২৬টির মধ্যে ২৪টি মারা গেল: ২৪ ÷ ২৬ = ৯২.৩১%. সীমানার test যোগ করে আবার চালালে সত্যিকারের ফল 25 killed, 1 survived, score 96.15. বাকি একটি mutant কেন মরে না? toLocaleString-এ সংখ্যা দেখানোর ডিফল্ট সীমা তিন দশমিক ঘর। পয়সার পূর্ণসংখ্যাকে ১০০ দিয়ে ভাগ করলে দশমিকের পরে কখনো দুই ঘরের বেশি হয় না, তাই { maximumFractionDigits: 2 } থাকা আর না থাকা একই ফল দেয়। এমন mutant-কে বলে equivalent mutant: কোড বদলেছে, আচরণ বদলায়নি, তাই কোনো test তাকে মারতে পারবে না। Mutation testing-এর ফল তাই মানুষকে পড়ে বিচার করতে হয়; ১০০% score তাড়া করা এখানেও ভুল লক্ষ্য।

দাম মনে রাখুন: প্রতিটি mutant-এর জন্য test আবার চলে। এই ছোট ফাইলে ২ সেকেন্ড লাগল, বড় project-এ ঘণ্টা লাগতে পারে। তাই সাধারণ পথ হলো টাকা আর অনুমতির মতো গুরুত্বপূর্ণ কয়েকটি module-এ চালানো, অথবা শুধু বদলানো ফাইলে। Stryker-এর --incremental বিকল্প আগের ফল মনে রেখে শুধু বদলানো অংশ আবার চালায়; ব্যবহারের আগে আপনার version-এর docs দেখে নিন।

১০ · AI-এর যুগে test — পাস করে, অথচ কিছুই যাচাই করে না

AI-কে “calcTotal-এর test লিখে দাও” বললে সে মুহূর্তে test দেয়, আর সেগুলো সবুজও হয়। প্রশ্ন হলো, সেগুলো কিছু ধরে কি না। ল্যাবে এমন ধাঁচের তিনটি test লিখলাম, যেমনটা প্রায়ই দেখা যায়:

it('should calculate total correctly', () => {
  const result = calcTotal(items, 'EID10');
  expect(result).toBeDefined();
  expect(result.total).toBeGreaterThan(0);
});
it('should handle a big cart', () => {
  const r = calcTotal([{ pricePaisa: 300000, qty: 1 }]);
  expect(r.total).toBe(r.subtotal - r.discount + r.delivery); // restates the code
});
it('should handle empty cart', () => {
  expect(() => calcTotal([])).not.toThrow();
});

সত্যিকারের run-এর ফল: তিনটিই পাস। price.js-এ coverage: statement 92.85, branch 100. দেখতে চমৎকার। এবার একই test দিয়ে Stryker:

~/bazarghar$ npx stryker run      # same price.js, only the three tests above
[Survived] MethodExpression
-     if (coupon === 'EID10') discount = Math.min(Math.round(subtotal * 0.1), EID_CAP);
+     if (coupon === 'EID10') discount = Math.max(Math.round(subtotal * 0.1), EID_CAP);
[Survived] ArithmeticOperator
-     const afterDiscount = subtotal - discount;
+     const afterDiscount = subtotal + discount;
…
File      |  total | covered | # killed | # timeout | # survived | # no cov | # errors |
All files |  23.08 |   28.57 |        6 |         0 |         15 |        5 |        0 |

Branch coverage ১০০%, mutation score ২৩.০৮%. ছাড় যোগ হলেও, সীমা উল্টে Math.max হলেও, ডেলিভারির শর্ত উল্টে গেলেও কোনো test লাল হয় না। পাঁচটি mutant formatTaka-তে, যেখানে কোনো test পৌঁছায়ইনি (no cov); তাই মোট ২৬-এর মধ্যে ৬, কিন্তু যেখানে test পৌঁছেছে সেই ২১-এর মধ্যে ৬, অর্থাৎ ২৮.৫৭%. ফাঁকা test-এর সাধারণ চেহারাগুলো:

AI-কে test লেখাতে চাইলে কোড নয়, নিয়ম আর কিনারা আগে দিন। তারপর ফল যাচাইয়ের দায় নিজের কাছে রাখুন।

AI-এর লেখা test হাতে পেলে

• প্রতিটি assertion-এ নির্দিষ্ট মান আছে, আর মানটি নিয়ম থেকে নিজে হিসাব করে মিলিয়েছি
• কোডে একটি ছোট ভুল ঢুকিয়ে দেখেছি অন্তত একটি test লাল হয়, অথবা Stryker চালিয়েছি
• যে কোড test হচ্ছে, তাকে mock করা হয়নি; নকল শুধু বাইরের সেবায়
• Test-এর API আমার Vitest, Testing Library আর Playwright-এর version-এর docs-এর সাথে মিলিয়েছি
• নতুন কোনো package যোগ হলে তার দরকার আর আসল অস্তিত্ব যাচাই করেছি; test-এ কোনো আসল secret নেই