টেস্টিং — Vitest আর Playwright দিয়ে নিশ্চিন্তে কোড বদলানো

১ · টেস্ট কী, আর কেন — কয়েক সেকেন্ডের নিরাপত্তা জাল

ধরুন আপনি একটি অনলাইন দোকানের কার্ট বানিয়েছেন। মোট দাম, ১৫% VAT আর কুপন ছাড় — সব ঠিকঠাক চলছে। এক মাস পরে ছাড়ের নিয়ম একটু বদলাতে হলো। সাধারণ উপায়: অ্যাপ খুলে কয়েকটি পণ্য কার্টে দেওয়া, কুপন বসানো, মোট দেখা — পাঁচ মিনিট, আর যাচাই হলো হয়তো তিনটি অবস্থা। খালি কার্ট, ঋণাত্মক পরিমাণ, ১০০% ছাড় দেখাই হলো না।

স্বয়ংক্রিয় টেস্ট (automated test) এই কাজটি কোডকে দিয়ে করায়। একটি টেস্ট হলো ছোট একটি প্রোগ্রাম, যা আপনার কোডকে জানা input দিয়ে চালায় আর ফল প্রত্যাশিত মানের সাথে মেলায়। মিললে পাস, না মিললে ফেল — সাথে কারণ। একবার লিখলে টেস্ট হাজারবার চলে, প্রতিবার একই মনোযোগ নিয়ে, কয়েক মিলিসেকেন্ডে।

টেস্ট লেখার চারটি বড় কারণ আছে। প্রতিটি আলাদা সমস্যা সারায়:

একটি ভুল ধারণা আগেই দূর করা যাক: টেস্ট প্রমাণ করে না যে কোডে বাগ নেই। টেস্ট শুধু দেখায়, যে অবস্থাগুলো আপনি ভেবেছেন, সেগুলোতে কোড ঠিক চলে। তাই কোন অবস্থাগুলো ভাববেন, সেটিই আসল দক্ষতা — অংশ ৪-এ। পর্ব ২১-এর খরচের খাতায় আপনি self-test লিখেছিলেন, আর পর্ব ২৯-এ console.assert দেখেছিলেন। এই পর্বে সেই ধারণাই পেশাদার রূপ পাবে: আলাদা টেস্ট ফাইল, একটি test runner, আর প্রতিটি push-এ স্বয়ংক্রিয়ভাবে চলা।

২ · টেস্টের তিন স্তর — pyramid, trophy আর static analysis

সব টেস্ট এক রকম নয়। কোনোটি একটি function একা দেখে, কোনোটি আসল ব্রাউজারে পুরো দোকান চালায়। মূল দ্বন্দ্ব হলো গতি বনাম বাস্তবতা: যত বাস্তব টেস্ট, তত ধীর আর তত ভঙ্গুর।

এই স্তরগুলো কতটুকু করে রাখবেন, তা নিয়ে দুটি জনপ্রিয় ছবি আছে। Testing pyramid: নিচে চওড়া ভিত্তি — অনেক unit টেস্ট; মাঝে কম integration; চূড়ায় অল্প কয়েকটি E2E. যুক্তি সহজ: সস্তা টেস্ট বেশি, দামি টেস্ট কম। Testing trophy একটু ভিন্ন কথা বলে: সবচেয়ে নিচে static analysis, আর সবচেয়ে মোটা অংশ integration — কারণ ফ্রন্টএন্ডে বেশিরভাগ বাগ লুকিয়ে থাকে অংশগুলোর জোড়ায়, একক function-এ নয়। দুটির ইতিহাস আর বিতর্ক ভাবনার প্রশ্ন ৩-এ।

৩ · একটি টেস্টের গঠন — Arrange, Act, Assert আর assertion

প্রায় প্রতিটি ভালো টেস্ট তিনটি অংশে লেখা যায়। একে বলে Arrange-Act-Assert (AAA):

• Arrange (সাজানো): input, প্রাথমিক অবস্থা আর দরকারি নকল জিনিস তৈরি।
• Act (করা): যা যাচাই করছেন, ঠিক সেই একটি কাজ — সাধারণত একটি function কল।
• Assert (মেলানো): ফল প্রত্যাশিত মানের সাথে মেলানো। এটি করে একটি assertion — না মিললে ভুল ছোড়ে, আর runner সেই টেস্টকে ফেল ধরে।

Vitest বা Jest-এ টেস্ট দেখতে এমন। describe কয়েকটি টেস্টকে একটি দলে রাখে (test suite), আর it বা test (দুটি একই জিনিস) একটি টেস্ট। নাম লিখুন সাধারণ ভাষায়, একটি আচরণের বাক্য হিসেবে — যাতে ফেল করলে শুধু নাম পড়েই বোঝা যায় কী ভাঙল:

import { describe, it, expect } from "vitest";
import { subtotal, applyDiscount, withVat } from "./cart.js";

describe("cart", () => {
  it("খালি কার্টে subtotal ০", () => {
    expect(subtotal([])).toBe(0);
  });

  it("দাম × পরিমাণ যোগ করে (পয়সায়)", () => {
    const items = [{ price: 12000, qty: 2 }, { price: 60000, qty: 1 }];  // Arrange
    const result = subtotal(items);                                      // Act
    expect(result).toBe(84000);                                          // Assert — ৳৮৪০
  });

  it("১০% ছাড় আর ১৫% VAT", () => {
    expect(applyDiscount(84000, 10)).toBe(75600);
    expect(withVat(75600)).toBe(86940);
  });

  it("ঋণাত্মক qty দিলে RangeError", () => {
    expect(() => subtotal([{ price: 100, qty: -1 }])).toThrow(RangeError);
  });
});

লক্ষ করুন, দাম রাখা হয়েছে পয়সায় (৳১২০ = ১২০০০ পয়সা), পূর্ণসংখ্যা হিসেবে। পর্ব ১০-এ দেখেছেন, 0.1 + 0.2 ঠিক 0.3 নয় — টাকার হিসাবে দশমিক floating-point ব্যবহার করলে টেস্ট (আর হিসাব) এক পয়সার জন্য ভাঙতে পারে। টার্মিনালে npx vitest run চালালে প্রত্যাশিত আউটপুট মোটামুটি এমন (সময় আপনার মেশিনে আলাদা হবে):

 ✓ src/cart.test.js (4 tests) 3ms

 Test Files  1 passed (1)
      Tests  4 passed (4)
   Duration  412ms

Assertion-এর ধরন — কোনটি কখন

সবচেয়ে বেশি ভুল হয় প্রথম দুটিতে। expect({ taka: 840 }).toBe({ taka: 840 }) ফেল করে — দুটি আলাদা object, দেখতে এক হলেও (পর্ব ১৪-এর reference). এবার একটি test framework ভেতরে কীভাবে কাজ করে, তা নিজে দেখুন — মাত্র কয়েক লাইনে test আর expect বানিয়ে। শেষ দুটি টেস্ট ইচ্ছা করে ভাঙা:

function test(name, fn) {                          // একটি টেস্ট = নাম + একটি function
  try { fn(); console.log("✓", name); }
  catch (e) { console.log("✗", name, "→", e.message); }
}
const show = JSON.stringify;
function expect(actual) {                          // assertion: না মিললে throw
  return {
    toBe(exp) { if (!Object.is(actual, exp)) throw new Error(`চেয়েছি ${show(exp)}, পেলাম ${show(actual)}`); },
    toEqual(exp) { if (show(actual) !== show(exp)) throw new Error(`চেয়েছি ${show(exp)}, পেলাম ${show(actual)}`); },
    toThrow() { try { actual(); } catch { return; } throw new Error("throw হওয়ার কথা ছিল, হয়নি"); },
  };
}
function cartTotal(items) {                        // যে কোড টেস্ট করছি
  if (items.some((it) => !(it.qty > 0))) throw new RangeError("qty ধনাত্মক হতে হবে");
  return items.reduce((sum, it) => sum + it.price * it.qty, 0);
}
test("খালি কার্টে মোট ০", () => expect(cartTotal([])).toBe(0));
test("২ × ১২০ + ১ × ৬০০ = ৮৪০", () =>
  expect(cartTotal([{ price: 120, qty: 2 }, { price: 600, qty: 1 }])).toBe(840));
test("ঋণাত্মক qty দিলে throw", () => expect(() => cartTotal([{ price: 50, qty: -1 }])).toThrow());
test("object-এ toEqual মেলে", () => expect({ taka: 840 }).toEqual({ taka: 840 }));
test("object-এ toBe ভাঙে", () => expect({ taka: 840 }).toBe({ taka: 840 }));
test("দশমিক টাকা: ০.১ × ৩", () => expect(cartTotal([{ price: 0.1, qty: 3 }])).toBe(0.3));

একটি টেস্ট রান ভেতরে — সংগ্রহ, প্রস্তুতি, চালানো, রিপোর্ট

Runner আপনার টেস্ট ফাইল পড়ার সাথে সাথে টেস্ট চালায় না। প্রথমে সে শুধু তালিকা বানায়, তারপর একটি একটি করে চালায়। প্রতিটি টেস্টের আগে beforeEach নামের একটি hook চলে, যা নতুন করে প্রস্তুতি নেয় — যাতে একটি টেস্টের রেখে যাওয়া অবস্থা পরেরটিকে ছুঁতে না পারে। নিচের কার্টে একটি বাগ আছে: VAT যোগ করতে 1.15 দিয়ে গুণ করার কথা, ভুলে লেখা হয়েছে 1.5. ধাপে ধাপে দেখুন:

1describe("Cart", () => {2  let cart;3  beforeEach(() => {4    cart = new Cart();5  });6  it("একটি পণ্যে মোট ১২০", () => {7    cart.add({ price: 120, qty: 1 });8    expect(cart.total()).toBe(120);9  });10  it("৮৪০-এ ১৫% VAT যোগে ৯৬৬", () => {11    cart.add({ price: 120, qty: 2 });12    cart.add({ price: 600, qty: 1 });13    expect(cart.totalWithVat()).toBe(966);14  });15});

৪ · কী টেস্ট করবেন — pure function আগে, তারপর edge case

সবচেয়ে সহজে টেস্ট হয় pure function (পর্ব ২৩): একই input-এ সবসময় একই output, বাইরের কিছু বদলায় না। নেটওয়ার্ক নেই, ঘড়ি নেই, DOM নেই — শুধু input দিন, output মেলান। তাই পর্ব ২১-এর functional core, imperative shell নীতি টেস্টের জন্যও সোনা: হিসাবের সব যুক্তি pure function-এ রাখুন (subtotal, applyDiscount, withVat), আর DOM বা fetch থাকুক পাতলা একটি বাইরের খোলসে। Core-এ হাজারটি দ্রুত unit টেস্ট, খোলসে অল্প কয়েকটি integration টেস্ট।

Edge case — বাগ যেখানে লুকিয়ে থাকে

“২টি পণ্য, ৳৮৪০” — এমন সাধারণ উদাহরণ প্রায় সবসময় কাজ করে। বাগ থাকে সীমানায়, যাকে বলে edge case. একটি কার্ট মডিউলের জন্য একটি তালিকা বানান, আর প্রতিটির জন্য আগে ঠিক করুন সঠিক আচরণ কী:

শেষ কলামটি আসলে পণ্যের সিদ্ধান্ত — টেস্ট লেখা মানে স্পেসিফিকেশন লেখা, তাই প্রশ্নগুলো প্রথম ভুল অর্ডারের দিনের আগেই সামনে আসে।

একটি টেবিল, অনেক টেস্ট — বাংলাদেশি ফোন নম্বর

পর্ব ৩০-এ আপনি regex দিয়ে বাংলাদেশি মোবাইল নম্বর যাচাই করেছিলেন। এমন function-এ একই আকৃতির অনেক কেস থাকে। প্রতিটির জন্য আলাদা it না লিখে একটি টেবিল দিন — Vitest-এর it.each প্রতিটি সারির জন্য একটি আলাদা টেস্ট তৈরি করে:

import { describe, it, expect } from "vitest";
import { isBdPhone } from "./phone.js";
// phone.js: export const isBdPhone = (s) => /^(?:\+?880|0)1[3-9]\d{8}$/.test(s.replace(/[\s-]/g, ""));

describe("isBdPhone", () => {
  it.each([
    ["01712345678", true],
    ["+8801712345678", true],
    ["01712-345678", true],        // মাঝে হাইফেন — মানুষ এভাবেই লেখেন
    ["01212345678", false],        // 012 দিয়ে কোনো অপারেটর নেই
    ["0171234567", false],         // এক অঙ্ক কম
    ["০১৭১২৩৪৫৬৭৮", false],        // বাংলা অঙ্ক: \d শুধু 0-9 মেলায়
    ["", false],
  ])("%s → %s", (input, expected) => {
    expect(isBdPhone(input)).toBe(expected);
  });
});

৫ · Test double — নকল fetch, নকল ঘড়ি আর dependency injection

বাস্তব কোড pure নয়। loadProducts() সার্ভার থেকে পণ্য আনে, debounced search ৩০০ ms অপেক্ষা করে, অর্ডারের পরে SMS যায়। এগুলো আসল অবস্থায় টেস্ট করলে তিনটি সমস্যা: ধীর (নেটওয়ার্কে সেকেন্ড লাগে), অনিশ্চিত (সার্ভার বন্ধ, ডেটা বদলে গেছে, load-shedding), আর ক্ষতিকর (প্রতিটি টেস্টে সত্যিকারের SMS!). সমাধান হলো আসল নির্ভরতার জায়গায় একটি নকল বসানো — যাকে সাধারণভাবে বলে test double, সিনেমার স্টান্ট ডাবলের মতো।

Dependency injection — নকল বসানোর দরজা

নকল বসাতে হলে কোডে একটি দরজা লাগে। যে function নিজের ভেতরে সরাসরি global fetch ডাকে, তার fetch বদলানো কঠিন। কিন্তু যদি fetch বাইরে থেকে দেওয়া হয় — loadProducts(fetchFn = fetch) — তাহলে টেস্টে একটি নকল দেওয়া যায়, আর অ্যাপে ডিফল্ট আসলটি চলে। নির্ভরতা ভেতরে তৈরি না করে বাইরে থেকে নেওয়ার এই নকশাকে বলে dependency injection. একই কৌশল ঘড়ির জন্য (now = new Date() parameter), random-এর জন্য, আর SMS পাঠানোর জন্য। নিচের ধাপগুলোতে দেখুন, নকল fetch কী বদলায়:

async function loadProducts(fetchFn = fetch) {
  const res = await fetchFn("/api/products");
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return (await res.json()).map((p) => p.name);
}
// অ্যাপে: loadProducts()  → ডিফল্ট, আসল fetch

✗ সার্ভার বন্ধ            → টেস্ট লাল, অথচ কোডে ভুল নেই
✗ নতুন পণ্য যোগ হলো       → প্রত্যাশিত তালিকা আর মেলে না
✗ ধীর নেটওয়ার্ক         → প্রতিটি টেস্টে ১–৩ সেকেন্ড
✗ 500 কীভাবে ঘটাব?       → ভুলের পথ টেস্টই করা যায় না

const fakeFetch = mock.fn(async () =>
  new Response('[{"name":"শাড়ি"},{"name":"লুঙ্গি"}]'));
// stub: সবসময় এই দুটি পণ্য
// spy:  প্রতিটি কল fakeFetch.mock.calls-এ জমা

const names = await loadProducts(fakeFetch);
assert.deepEqual(names, ["শাড়ি", "লুঙ্গি"]);   ✓

fakeFetch.mock.callCount()               // 1
fakeFetch.mock.calls[0].arguments[0]     // "/api/products"
// ভুলের পথ: async () => new Response("", { status: 500 })
//          → await assert.rejects(..., /HTTP 500/)  ✓

Fake timers — ৩০০ ms অপেক্ষা না করে debounce যাচাই

পর্ব ৩৬-এর debounce টেস্ট করতে চাইলে সত্যিই ৩০০ ms অপেক্ষা করবেন? একশোটি টেস্টে ৩০ সেকেন্ড, আর ব্যস্ত CI মেশিনে timer একটু দেরি করলে টেস্ট মাঝে মাঝে ফেল। Fake timers আসল setTimeout-এর জায়গায় একটি নকল ঘড়ি বসায়, যা শুধু টেস্ট নিজে এগিয়ে দিলে এগোয়: “এবার ২৯৯ ms এগোও” — আর সেই সময়ের মধ্যে বাজার কথা এমন সব timer সাথে সাথে চলে যায়।

Node.js 20-এর ভেতরেই একটি test runner আছে — node:test মডিউল, Node 20-এ stable — সাথে mock.fn() আর mock.timers. নিচের কোডে সেগুলো আর node:assert/strict দিয়ে debounce আর নকল fetch-এর তিনটি টেস্ট। node --test চালালে আসল runner প্রতিটি টেস্টের সময়সহ লম্বা রিপোর্ট দেয়, যা প্রতিবার একটু আলাদা আসে। তাই এখানে আউটপুট স্থির রাখতে একটি তিন লাইনের check() runner ব্যবহার করা হয়েছে:

const { mock } = require("node:test");               // Node 20-এর built-in টেস্ট টুল
const assert = require("node:assert/strict");
process.removeAllListeners("warning");               // MockTimers এখনো "experimental" — সতর্কবার্তা লুকাই
async function check(name, fn) {                     // ছোট্ট runner: পাস হলে ✓, ভাঙলে ✗
  try { await fn(); console.log("✓", name); } catch (e) { console.log("✗", name, "→", e.message); }
}
const debounce = (fn, wait) => { let id; return (...a) => { clearTimeout(id); id = setTimeout(() => fn(...a), wait); }; };
async function loadProducts(fetchFn) {               // fetch বাইরে থেকে আসে — dependency injection
  const res = await fetchFn("/api/products");
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return (await res.json()).map((p) => p.name);
}
(async () => {
  await check("debounce: টাইপ থামার ৩০০ ms পরে একবারই খোঁজে", () => {
    mock.timers.enable({ apis: ["setTimeout"] });    // আসল ঘড়ির বদলে নকল ঘড়ি
    const search = mock.fn();                        // spy: কতবার, কী দিয়ে ডাকা হলো
    const onType = debounce(search, 300);
    onType("শা"); onType("শাড়"); onType("শাড়ি");
    mock.timers.tick(299); assert.equal(search.mock.callCount(), 0);
    mock.timers.tick(1);   assert.deepEqual(search.mock.calls.map((c) => c.arguments), [["শাড়ি"]]);
    mock.timers.reset();
  });
  await check("loadProducts: নকল fetch থেকে পণ্যের নাম আনে", async () => {
    const fakeFetch = mock.fn(async () => new Response('[{"name":"শাড়ি"},{"name":"লুঙ্গি"}]'));
    assert.deepEqual(await loadProducts(fakeFetch), ["শাড়ি", "লুঙ্গি"]);
    assert.equal(fakeFetch.mock.calls[0].arguments[0], "/api/products");
  });
  await check("loadProducts: সার্ভার 500 দিলে reject করে", () =>
    assert.rejects(loadProducts(async () => new Response("", { status: 500 })), /HTTP 500/));
})();

Async কোড টেস্টের একটি নিয়ম মনে রাখুন: প্রতিটি Promise-কে await করুন, বা ফেরত দিন। expect(p).rejects.toThrow()-এর আগে await ভুলে গেলে টেস্ট function শেষ হয়ে যায় Promise মীমাংসার আগেই। Jest-এর মতো runner তখন পাস দেখাতে পারে, অথচ আসল যাচাইটি ঘটেইনি; Vitest-এর সাম্প্রতিক version এমন না-await করা assertion নিয়ে সতর্ক করে। AI-এর লেখা টেস্টে এই ভুলটি প্রায়ই দেখা যায়।

৬ · Vitest, Testing Library, snapshot আর coverage

আজকের নতুন JavaScript প্রজেক্টে সবচেয়ে প্রচলিত test runner-গুলোর একটি Vitest. এটি তৈরি Vite-এর (পর্ব ৪৬) ওপর: আপনার অ্যাপ যে config আর রূপান্তর (TypeScript, JSX, ESM) দিয়ে চলে, টেস্টও সেভাবেই চলে — আলাদা Babel সেটআপ লাগে না। আর API প্রায় হুবহু Jest-এর মতো, তাই পুরোনো Jest টেস্ট সামান্য বদলেই চলে।

npm install -D vitest
npx vitest                # watch mode: ফাইল সেভ করলেই সংশ্লিষ্ট টেস্ট আবার চলে
npx vitest run            # একবার চালিয়ে থামে — CI-তে এটিই
npx vitest run --coverage # কোন লাইন টেস্টে চলেছে তার হিসাব

Watch mode দৈনন্দিন কাজের ধরন বদলে দেয়: এক পাশে কোড, অন্য পাশে টার্মিনাল; সেভ চাপামাত্র শুধু প্রভাবিত টেস্টগুলো আধা সেকেন্ডে চলে। আগের অংশের নকলগুলো Vitest-এ vi object-এ থাকে:

import { vi, it, expect, beforeEach, afterEach } from "vitest";
import { debounce } from "./debounce.js";
import { loadProducts } from "./products.js";

beforeEach(() => vi.useFakeTimers());                 // নকল ঘড়ি
afterEach(() => { vi.useRealTimers(); vi.unstubAllGlobals(); });

it("debounce: থামার ৩০০ ms পরে একবার", () => {
  const search = vi.fn();
  const onType = debounce(search, 300);
  onType("শা"); onType("শাড়ি");
  vi.advanceTimersByTime(299);
  expect(search).not.toHaveBeenCalled();
  vi.advanceTimersByTime(1);
  expect(search).toHaveBeenCalledOnce();
  expect(search).toHaveBeenCalledWith("শাড়ি");
});

it("global fetch বদলে পণ্য লোড", async () => {
  const fakeFetch = vi.fn().mockResolvedValue(new Response('[{"name":"শাড়ি"}]'));
  vi.stubGlobal("fetch", fakeFetch);
  await expect(loadProducts()).resolves.toEqual(["শাড়ি"]);
});

// পুরো একটি module নকল করা (পর্ব ৪৫-এর import):
// vi.mock("./api.js", () => ({ getProducts: vi.fn(async () => []) }));

vi.stubGlobal কাজে লাগে যখন কোড dependency injection ছাড়াই global fetch ডাকে। vi.mock পুরো একটি module-এর import বদলে দেয় — কিন্তু যত বেশি module নকল, টেস্ট তত বেশি নিজের কল্পনা যাচাই করে। নিয়ম: সীমানার বাইরের জিনিস (নেটওয়ার্ক, ঘড়ি, payment gateway) নকল করুন; নিজের module যতটা পারেন আসল রাখুন।

DOM টেস্ট — jsdom আর Testing Library

Vitest ডিফল্টভাবে Node-এ চলে, যেখানে document নেই। DOM-এর কোড টেস্ট করতে একটি নকল ব্রাউজার পরিবেশ লাগে — jsdom বা তার দ্রুততর বিকল্প happy-dom. ফাইলের শুরুতে // @vitest-environment jsdom লিখুন, বা config-এ environment: "jsdom". এটি আসল ব্রাউজার নয় — layout নেই, CSS-এর হিসাব নেই — কিন্তু DOM, event আর form-এর জন্য যথেষ্ট আর অনেক দ্রুত।

এবার প্রশ্ন: পাতায় element খুঁজবেন কীভাবে? document.querySelector(".btn-primary-2") লিখলে টেস্ট একটি CSS class-এর ওপর নির্ভর করে, যা ডিজাইনার কাল বদলাবেন। Testing Library-এর দর্শন ভিন্ন: ব্যবহারকারী যেভাবে পাতা দেখেন, টেস্টও সেভাবে খুঁজবে। ব্যবহারকারী class দেখেন না; দেখেন “কার্টে যোগ করুন” লেখা একটি বোতাম। Screen reader-ও ঠিক এভাবেই পাতা পড়ে — role আর নাম দিয়ে:

// @vitest-environment jsdom
import { it, expect } from "vitest";
import { screen } from "@testing-library/dom";
import userEvent from "@testing-library/user-event";
import { mountShop } from "./shop.js";

it("‘কার্টে যোগ করুন’ চাপলে কার্টের সংখ্যা বাড়ে", async () => {
  document.body.innerHTML = '<main id="app"></main>';
  mountShop(document.getElementById("app"));
  const user = userEvent.setup();

  await user.click(screen.getByRole("button", { name: "মধু কার্টে যোগ করুন" }));
  await user.type(screen.getByLabelText("পরিমাণ"), "2");

  expect(screen.getByRole("status").textContent).toBe("কার্টে ২টি পণ্য");
});

Snapshot টেস্ট — সুবিধাজনক, কিন্তু ফাঁদ

Snapshot testing-এ আপনি প্রত্যাশিত মান হাতে লেখেন না। expect(renderReceipt(order)).toMatchSnapshot() প্রথমবার চললে ফলটি একটি .snap ফাইলে সেভ হয়; পরেরবার থেকে নতুন ফল সেই ফাইলের সাথে মেলানো হয়, আর পার্থক্য থাকলে diff দেখিয়ে ফেল। বড় output (একটি রসিদের HTML, একটি জটিল JSON) হঠাৎ বদলে গেলে ধরার জন্য এটি দ্রুত উপায়।

Coverage — কতটুকু চলেছে, কতটুকু যাচাই হয়েছে নয়

Code coverage জানায় টেস্ট চলার সময় কোডের কত শতাংশ লাইন, শাখা (if-এর দুই দিক) আর function অন্তত একবার চলেছে। এটি খুব কাজের একটি মানচিত্র: লাল অংশ মানে সেখানে কোনো টেস্টই যায়নি — হয়তো ভুলের পথ, হয়তো ১০০% ছাড়ের শাখা।

কিন্তু ১০০% coverage মানে “১০০% সঠিক” নয়। Coverage শুধু দেখে লাইনটি চলেছে কি না, ফলটি যাচাই হয়েছে কি না নয়। it("withVat", () => { withVat(1000); }) — কোনো assertion নেই, তবু withVat-এর প্রতিটি লাইন “covered”. তাই coverage-কে লক্ষ্য না বানিয়ে প্রশ্নের উৎস বানান: “এই লাল শাখাটি কেন টেস্ট হয়নি?” আর টেস্ট সত্যিই কিছু যাচাই করে কি না মাপার আরও কঠিন উপায় — mutation testing — ভাবনার প্রশ্ন ৫-এ।

৭ · Playwright — আসল ব্রাউজারে end-to-end, আর flaky টেস্ট

Unit আর integration টেস্ট সব সবুজ, তবু চেকআউট বোতাম কাজ না-ও করতে পারে: হয়তো CSS একটি স্বচ্ছ স্তর দিয়ে বোতাম ঢেকে দিয়েছে, হয়তো Safari-তে একটি API নেই, হয়তো সার্ভারের route বদলে গেছে। এগুলো ধরে শুধু আসল ব্রাউজারে আসল অ্যাপ চালানো টেস্ট। Playwright (Microsoft, ২০২০) একই কোডে তিনটি ইঞ্জিনে টেস্ট চালায় — Chromium (Chrome/Edge), Firefox আর WebKit (Safari-র ইঞ্জিন)। সাধারণত চলে headless, অর্থাৎ জানালা না দেখিয়ে।

import { test, expect } from "@playwright/test";

test("কার্টে যোগ করে চেকআউটে মোট ৳৮৪০ দেখায়", async ({ page }) => {
  await page.goto("/");                                         // baseURL config থেকে

  await page.getByRole("button", { name: "চা-পাতা কার্টে যোগ করুন" }).click();
  await page.getByRole("button", { name: "চা-পাতা কার্টে যোগ করুন" }).click();
  await page.getByRole("button", { name: "মধু কার্টে যোগ করুন" }).click();
  await expect(page.getByRole("status")).toHaveText("কার্টে ৩টি পণ্য");

  await page.getByRole("link", { name: "চেকআউট" }).click();
  await expect(page).toHaveURL(/\/checkout$/);
  await expect(page.getByLabel("সর্বমোট")).toHaveText("৳৮৪০");   // ২ × ১২০ + ৬০০
});

npm init playwright@latest               # config, উদাহরণ আর ব্রাউজার ইনস্টল
npx playwright test                      # তিন ব্রাউজারে সব টেস্ট, একসাথে কয়েকটি worker-এ
npx playwright test --project=webkit     # শুধু Safari-র ইঞ্জিনে
npx playwright codegen localhost:5173    # ব্রাউজারে ক্লিক করুন, Playwright কোড লিখে দেয়
npx playwright show-report               # HTML রিপোর্ট; ফেল হলে trace খুলুন

দুটি টুল বিশেষভাবে কাজের। Codegen আপনার ক্লিক আর টাইপ রেকর্ড করে টেস্টের খসড়া লেখে — শুরুর জন্য ভালো, তবে বানানো locator আর assertion পরে নিজে গুছিয়ে নিন। Trace viewer একটি ফেল টেস্টের পুরো রেকর্ড দেখায়: প্রতিটি ধাপের আগে-পরে পাতার DOM snapshot, network request, console বার্তা — যেন সময়ে পিছিয়ে গিয়ে দেখা। Config-এ trace: "on-first-retry" দিলে CI-তে প্রথম retry-তে trace সেভ হয়, তাই CI-তে ফেল হওয়া টেস্টও নিজের মেশিনে খুঁটিয়ে দেখা যায়।

Flaky টেস্ট — কখনো পাস, কখনো ফেল

কোড একটুও না বদলে একই টেস্ট কখনো সবুজ, কখনো লাল — একে বলে flaky test. এটি শুধু বিরক্তিকর নয়, বিপজ্জনক: দল একবার “ওহ, ওটা মাঝে মাঝে এমনি লাল হয়” বলতে শিখলে আসল ভুলের লাল সংকেতও উপেক্ষা করবে। প্রায় সব flaky টেস্টের পেছনে তিনটি কারণ:

Retry (ফেল হলে আবার চালানো) শুধু লক্ষণ লুকায়, সমাধান নয়। কারণ খুঁজে ঠিক করুন, নইলে মুছে ফেলুন — অবিশ্বাসযোগ্য টেস্ট না থাকার চেয়েও খারাপ।

৮ · TDD, CI আর কী টেস্ট করবেন না

এ পর্যন্ত আগে কোড, পরে টেস্ট লিখেছি। Test-driven development (TDD) ক্রমটি উল্টে দেয়: আগে একটি ছোট, ব্যর্থ টেস্ট; তারপর সেটি পাস করানোর মতো ন্যূনতম কোড; তারপর পরিষ্কার করা। তিন রঙের একটি চক্র — red → green → refactor. একটি formatTaka function দিয়ে ধাপে ধাপে দেখুন, যা টাকার অঙ্ক বাংলায় দেখাবে:

it("৮৪০ → ৳৮৪০", () => {
  expect(formatTaka(840)).toBe("৳৮৪০");
});
× ৮৪০ → ৳৮৪০
  TypeError: formatTaka is not a function

export function formatTaka(n) {
  return "৳৮৪০";
}
✓ ৮৪০ → ৳৮৪০
// হাস্যকর? ইচ্ছা করেই। পরের টেস্ট একে সাধারণ হতে বাধ্য করবে।

it("১২৫০০০ → ৳১,২৫,০০০ (লাখ-কোটির নিয়মে)", () => {
  expect(formatTaka(125000)).toBe("৳১,২৫,০০০");
});
× expected '৳৮৪০' to be '৳১,২৫,০০০'

export function formatTaka(n) {
  return "৳" + new Intl.NumberFormat("bn-BD").format(n);
}
✓ ৮৪০ → ৳৮৪০
✓ ১২৫০০০ → ৳১,২৫,০০০

const bnNumber = new Intl.NumberFormat("bn-BD");   // একবার তৈরি

export const formatTaka = (n) => `৳${bnNumber.format(n)}`;
✓ ৮৪০ → ৳৮৪০
✓ ১২৫০০০ → ৳১,২৫,০০০
// পরের চক্র: ঋণাত্মক (ফেরত), পয়সা (৮৪০.৫০)…

স্পষ্ট নিয়মের হিসাব (টাকা, VAT, তারিখ) আর বাগ সারানোয় TDD দারুণ; নতুন UI-র নকশা খোঁজার সময় কম। তবে একটি অভ্যাস সবার জন্য: আগে বাগটি ঘটানো একটি ব্যর্থ টেস্ট, তারপর সমাধান। TDD-র বিতর্ক ভাবনার প্রশ্ন ২-এ।

CI — প্রতিটি push-এ সব টেস্ট

টেস্ট শুধু তখনই রক্ষা করে, যখন চলে। “আমি push-এর আগে চালাতে ভুলে গিয়েছিলাম” — এই সমস্যার সমাধান continuous integration (CI): প্রতিটি push বা pull request-এ একটি পরিষ্কার সার্ভারে নিজে থেকে সব টেস্ট চলে। লাল হলে merge আটকে যায়। GitHub Actions-এ এর জন্য রিপোজিটরিতে একটি ফাইলই যথেষ্ট:

name: test
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci                                  # lockfile মেনে হুবহু একই প্যাকেজ
      - run: npm run lint                            # static analysis — পর্ব ৪৬
      - run: npm test                                # vitest run
      - run: npx playwright install --with-deps
      - run: npx playwright test                     # E2E

ক্রমটি লক্ষ করুন — সস্তা আগে, দামি পরে। Lint এক সেকেন্ডে ব্যর্থ হলে মিনিট খানেকের E2E চালানোর দরকারই নেই। npm ci lockfile হুবহু মানে, তাই “আমার মেশিনে চলে” আর CI-র মধ্যে প্যাকেজের version-এ পার্থক্য থাকে না।

কী টেস্ট করবেন না

• Implementation detail: private helper, ভেতরের variable-এর নাম, কোন function কতবার ভেতরে ভেতরে ডাকা হলো, CSS class-এর নাম। এসব টেস্ট refactor-এর সময় অকারণে ভাঙে — অথচ refactor-এ সাহায্য করাই টেস্টের কাজ ছিল। যাচাই করুন আচরণ: public function কী ফেরত দেয়, পাতায় ব্যবহারকারী কী দেখেন।
• অন্যের লাইব্রেরি: Intl.NumberFormat বাংলা অঙ্ক দেয় কি না, বা React-এর useState কাজ করে কি না — তাদের নিজস্ব টেস্ট আছে। আপনি যাচাই করুন আপনার ব্যবহার: formatTaka ঠিক ফল দেয় কি না।

৯ · AI-এর যুগে — AI-এর লেখা টেস্ট কি আসলে কিছু যাচাই করে?

“এই function-এর টেস্ট লিখে দাও” — AI-কে দেওয়া সবচেয়ে প্রচলিত কাজগুলোর একটি, আর ফলও আসে চমৎকার দেখতে: বিশটি টেস্ট, সব সবুজ, coverage ৯৫%. বিপদটি ঠিক সেখানে। AI সাধারণত আপনার বাস্তবায়ন পড়ে টেস্ট লেখে, স্পেসিফিকেশন পড়ে নয়। ফলে কোডে যে বাগ আছে, টেস্টও সেটিকেই “সঠিক” ধরে নেয়।

AI টেস্টে সবচেয়ে কাজে লাগে edge case খুঁজে দিতে — যে অবস্থাগুলো আপনার মাথায় আসেনি। তাই কোড না দেখিয়ে নিয়মগুলো দিন, আগে কেসের তালিকা চান, নিজে review করুন, তারপর টেস্ট:

AI-এর লেখা টেস্ট হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রত্যাশিত মানগুলো আক্ষরিক আর হাতে যাচাই করা — কোডের সূত্র বা কোডের output কপি করে নয়
• কোডে ইচ্ছা করে একটি ছোট বাগ ঢুকিয়ে দেখেছি — অন্তত একটি টেস্ট লাল হয়েছে
• প্রতিটি টেস্টে অর্থবহ assertion আছে; প্রতিটি Promise await করা
• Mock শুধু সীমানার বাইরের জিনিসে (নেটওয়ার্ক, ঘড়ি); প্রধান assertion ফল বা আচরণের ওপর
• Edge case আছে: খালি, শূন্য, ঋণাত্মক, সীমা, বাংলা input, ভুলের পথ
• টেস্টগুলো একে অপরের থেকে স্বাধীন — যেকোনো ক্রমে, একা বা সবার সাথে পাস করে
• নামগুলো আচরণের বাক্য — ফেল করলে নাম পড়েই বোঝা যায় কী ভাঙল