Test pyramid আর integration test — contract test, end-to-end আর flaky test

১ · Test pyramid — কোন স্তরে কতগুলো test

পর্ব ৪৫-এ (Testing-এর মৌলিক) test-এর স্তরগুলো দেখেছেন: unit test, integration test, system test আর acceptance test. পর্ব ৪৬ থেকে ৫০-এ শিখেছেন ভালো unit test লেখা, test case নকশা, TDD, test double আর coverage. এই পর্বের প্রশ্ন আলাদা: একটি পুরো project-এ কোন স্তরে কতগুলো test রাখবেন, আর বড় test-গুলোকে কীভাবে বিশ্বাসযোগ্য রাখবেন।

সেই অনুপাতের সবচেয়ে পরিচিত ছবি test pyramid. Mike Cohn তাঁর Succeeding with Agile (২০০৯) বইয়ে “test automation pyramid” নামে ছবিটি জনপ্রিয় করেন; তাঁর নিজের বক্তব্য অনুযায়ী ধারণাটি নিয়ে তিনি এর কয়েক বছর আগে থেকেই কথা বলছিলেন। Cohn-এর তিনটি স্তর ছিল নিচ থেকে Unit, Service আর UI. পরে Martin Fowler-এর “TestPyramid” লেখা (২০১২) আর Ham Vocke-এর “The Practical Test Pyramid” (২০১৮, Fowler-এর ওয়েবসাইটে) ছবিটিকে আরও ছড়িয়ে দেয়। আজ মাঝের স্তরটিকে অনেকে integration বলেন, ওপরেরটিকে end-to-end (E2E).

কেন নিচে বেশি — চারটি কারণ

শেষ সারিটি খেয়াল করুন — ওপরের test-এর একটি অনন্য মূল্য আছে। তাই pyramid বলে না “E2E খারাপ”; বলে প্রতিটি ঝুঁকি সবচেয়ে নিচের যে স্তরে ধরা যায়, সেখানেই ধরুন. Discount-এর হিসাব ২০টি boundary-তে — ২০টি unit test; “discount-সহ অর্ডার সত্যিই database-এ জমা হয়” — একটি integration test; “ব্যবহারকারী coupon দিয়ে টাকা দিতে পারেন” — একটি E2E test.

২ · Pyramid-এর হিসাব — suite-এর সময় আর মিথ্যা লাল build

ছবির কথা হিসাবে নামানো যাক। দুটি সংখ্যা দলের প্রতিদিনের জীবন ঠিক করে: পুরো suite চলতে কত সময় লাগে, আর কোডে ভুল না থাকলেও build লাল হওয়ার সম্ভাবনা কত — একে বলে false failure বা মিথ্যা লাল।

সময়: T = Σ (test-এর সংখ্যা × একটি test-এর সময়)। কয়েকটি যন্ত্রে ভাগ করে চালালে আদর্শ অবস্থায় T ÷ যন্ত্রের সংখ্যা (অংশ ৯)।

মিথ্যা লাল: ধরুন একটি সুস্থ test একবার চালালে ভুল করে fail করার সম্ভাবনা p. তাহলে সেটি pass করার সম্ভাবনা (1 − p). n-টি এমন test স্বাধীনভাবে চললে সবগুলো pass করার সম্ভাবনা (1 − p)ⁿ, আর অন্তত একটি fail করে build লাল হওয়ার সম্ভাবনা

যেখানে i প্রতিটি স্তর। ছোট p-তে একটি কাজের অনুমান: 1 − (1 − p)ⁿ ≈ n × p, যতক্ষণ n × p ছোট (ধরুন ০.১-এর নিচে)। অর্থাৎ flaky হওয়ার সম্ভাবনা যোগ হয়: ৫০০-তে একবার flaky এমন ২০টি test মিলে প্রায় ৪% build মিথ্যা লাল করে।

নিচের মডেলে দুটি কাল্পনিক suite. প্রতিটি স্তরের সময় আর flaky-হার অনুমান — মাপা data নয়, শুধু আকারের পার্থক্য দেখানোর জন্য বেছে নেওয়া:

// Test-suite cost model. ASSUMPTIONS (invented for the model, not measured data):
// seconds per test and chance that ONE run of ONE healthy test fails anyway.
const LEVEL = {
  unit:        { sec: 0.005, flake: 0.00001 },   // 5 ms, 1 in 100,000
  integration: { sec: 0.5,   flake: 0.0002 },    // 0.5 s, 1 in 5,000
  e2e:         { sec: 20,    flake: 0.002 },     // 20 s, 1 in 500
};
const SUITES = {
  "pyramid":         { unit: 2000, integration: 200, e2e: 20 },
  "ice-cream cone":  { unit: 100,  integration: 50,  e2e: 300 },
};
const WORKERS = 8;                      // parallel machines in CI

function analyse(counts) {
  let sec = 0, pAllPass = 1;
  for (const [lvl, n] of Object.entries(counts)) {
    sec += n * LEVEL[lvl].sec;
    pAllPass *= Math.pow(1 - LEVEL[lvl].flake, n);  // independent flakes
  }
  return { sec, falseRed: 1 - pAllPass };
}

for (const [name, counts] of Object.entries(SUITES)) {
  const r = analyse(counts);
  const total = Object.values(counts).reduce((a, b) => a + b, 0);
  console.log(`${name}: ${total} tests`);
  console.log(`  serial time   : ${(r.sec / 60).toFixed(1)} min`);
  console.log(`  ${WORKERS} workers     : ${(r.sec / WORKERS / 60).toFixed(1)} min (ideal split)`);
  console.log(`  false red build: ${(100 * r.falseRed).toFixed(1)}% of runs`);
  console.log(`  20 runs/day -> ${(20 * r.falseRed).toFixed(1)} false alarms/day`);
}

pyramid: 2220 tests
  serial time   : 8.5 min
  8 workers     : 1.1 min (ideal split)
  false red build: 9.5% of runs
  20 runs/day -> 1.9 false alarms/day
ice-cream cone: 450 tests
  serial time   : 100.4 min
  8 workers     : 12.6 min (ideal split)
  false red build: 45.8% of runs
  20 runs/day -> 9.2 false alarms/day

৩ · অন্য আকার — trophy, honeycomb আর ice-cream cone

Pyramid সার্বজনীন সত্য নয়; এটি একটি নির্দিষ্ট যুগের, নির্দিষ্ট ধরনের system-এর পরামর্শ। পরের বছরগুলোতে কয়েকটি বিকল্প আকার এসেছে, প্রত্যেকটি একটি নির্দিষ্ট অভিযোগের উত্তরে।

তাহলে কী নেবেন? তিনটি আকারই একই প্রশ্নের ভিন্ন উত্তর: আপনার system-এ ঝুঁকি কোথায়? হিসাবের নিয়মে ভরা library-তে ঝুঁকি যুক্তিতে — pyramid; component-এ ভরা frontend-এ জোড়ায় — trophy; database আর API-তে কথা বলা ছোট service-এ সীমানায় — honeycomb. আর সব আকারেই দুটি কথা একই: ধীর, ভঙ্গুর E2E অল্প, আর ice-cream cone নয়। নামে আটকাবেন না — trophy-র “integration” প্রায়ই browser বা network ছাড়া, তাই দ্রুত; গতি আর স্থিরতা দেখুন।

৪ · Integration-এর কৌশল — big-bang, top-down, bottom-up আর sandwich

পাঠ্যবইয়ের (Pressman, Sommerville) পুরোনো প্রশ্ন: আলাদা আলাদা তৈরি module কোন ক্রমে জোড়া দিয়ে test করবেন? চারটি প্রচলিত উত্তর:

• Big-bang: সব module তৈরি হলে একবারে সব জোড়া, তারপর test. সহজ পরিকল্পনা, কিন্তু ব্যর্থ হলে কোন জোড়ায় ভুল — খুঁজে পাওয়া কঠিন, আর ভুল ধরা পড়ে একেবারে শেষে।
• Top-down: ওপরের নিয়ন্ত্রক module থেকে শুরু; নিচের যেগুলো এখনো তৈরি হয়নি, তাদের জায়গায় stub — ঠিক করা উত্তর দেওয়া নকল। একটি একটি করে stub-কে আসল module দিয়ে বদলান। সুবিধা: মূল প্রবাহ আর UI তাড়াতাড়ি দেখা যায়। অসুবিধা: অনেক stub লিখতে হয়, আর নিচের আসল আচরণ দেরিতে আসে।
• Bottom-up: সবচেয়ে নিচের module (database-এর adapter, payment client) থেকে শুরু; ওপরের ডাকার module-এর জায়গায় test driver — ছোট কোড, যা module-টিকে ডাকে আর ফল যাচাই করে। সুবিধা: ভিত্তি আগে পোক্ত। অসুবিধা: পুরো ব্যবহারকারীর প্রবাহ দেখা যায় শেষে।
• Sandwich (hybrid): ওপর থেকে stub দিয়ে আর নিচ থেকে driver দিয়ে একসাথে, মাঝের স্তরে মিলন। বড় project-এ দুটি দল সমান্তরালে কাজ করতে পারে।

নিচের stepper-এ একটি কাল্পনিক অনলাইন বাজার অ্যাপের চারটি module: OrderController (A, ওপরে), যে ডাকে OrderService (B), আর B ডাকে PaymentClient (C) আর InventoryRepo (D). ভেতরে একটি ভুল লুকানো: B টাকার অঙ্ক পাঠায় টাকায় (450), কিন্তু C ধরে নেয় অঙ্কটি পয়সায়।

আজকের দলে এই নামগুলো কম শোনা যায়, কারণ continuous integration (পর্ব ৫৮) দিনে কয়েকবার ছোট ছোট পরিবর্তন জোড়ে — কার্যত চিরস্থায়ী incremental integration. শিক্ষাটি একই: একসাথে যত কম নতুন জোড়া, ভুল খোঁজা তত সহজ। Stub আর driver আজ test double আর test harness নামে রোজকার হাতিয়ার (পর্ব ৪৯ Test double).

Narrow বনাম broad integration test

“Integration test” কথাটি এত রকম অর্থে ব্যবহার হয় যে Martin Fowler তাঁর “IntegrationTest” লেখায় (২০১৮) দুটি ভাগ প্রস্তাব করেন:

৫ · আসল dependency-র সাথে test — database, rollback আর test data

পর্ব ৪৯-এ দেখেছেন fake আর mock দিয়ে dependency আলাদা করা। কিন্তু একটি repository-র SQL ঠিক আছে কি না, তা fake দিয়ে প্রমাণ হয় না — fake-এর ভেতরে তো SQL-ই নেই। এখানে দরকার আসল database. বিকল্প দুটি:

Testcontainers একটি open-source library (Java দিয়ে শুরু, আনুমানিক ২০১৫; এখন নানা ভাষায়): test-এর আগে Docker-এ database container চালু করে, শেষে মুছে ফেলে। Python-এ মোটামুটি এমন (লেখার সময়ের API; documentation মিলিয়ে নিন):

import pytest, sqlalchemy
from testcontainers.postgres import PostgresContainer

@pytest.fixture(scope="session")
def engine():
    with PostgresContainer("postgres:16") as pg:      # same engine as production
        eng = sqlalchemy.create_engine(pg.get_connection_url())
        run_migrations(eng)                           # the real schema, not a copy
        yield eng                                     # container removed after the session

@pytest.fixture
def conn(engine):
    with engine.connect() as c:
        tx = c.begin()
        yield c                                       # the test runs inside this transaction
        tx.rollback()                                 # every write disappears

লক্ষ করুন দুটি কৌশল একসাথে: container চালু হয় একবার পুরো session-এ (ধীর কাজটি ভাগ করা), আর প্রতিটি test চলে নিজের transaction-এ, শেষে ROLLBACK — একে বলে transactional rollback. পরের test পায় পরিষ্কার database, কিন্তু নতুন container-এর খরচ ছাড়া। (Python-এর pytest fixture-এর খুঁটিনাটি Python · pytest দিয়ে testing-এ।)

নিজে চালিয়ে দেখুন — rollback দিয়ে পরিষ্কার অবস্থা

নিচের live SQL এডিটরে একটি কাল্পনিক অর্ডার repository-র দুটি test. প্রতিটি test একটি BEGIN দিয়ে শুরু, assertion হিসেবে একটি SELECT … CASE, আর শেষে ROLLBACK. Test ২ ধরে নেয় test শুরুর সময় customer ১-এর কোনো অর্ডার নেই:

-- test 1: saving an order stores its total
BEGIN;
INSERT INTO orders (id, customer_id, total) VALUES (101, 1, 450);
SELECT 'test 1' AS test,
  CASE WHEN (SELECT total FROM orders WHERE id = 101) = 450
       THEN 'PASS' ELSE 'FAIL' END AS result;
ROLLBACK;

-- test 2: a customer with one new order has exactly one order
BEGIN;
INSERT INTO orders (id, customer_id, total) VALUES (201, 1, 900);
SELECT 'test 2' AS test,
  CASE WHEN (SELECT COUNT(*) FROM orders WHERE customer_id = 1) = 1
       THEN 'PASS' ELSE 'FAIL' END AS result;
ROLLBACK;

SELECT COUNT(*) AS orders_left_after_suite FROM orders;

এবার একই suite, শুধু test ১-এর শেষে কেউ ভুল করে COMMIT লিখেছেন (বা test framework-এর কোনো ধাপ নিজেই commit করে ফেলে):

-- test 1, with a COMMIT by mistake
BEGIN;
INSERT INTO orders (id, customer_id, total) VALUES (101, 1, 450);
SELECT 'test 1' AS test,
  CASE WHEN (SELECT total FROM orders WHERE id = 101) = 450
       THEN 'PASS' ELSE 'FAIL' END AS result;
COMMIT;

-- test 2, unchanged
BEGIN;
INSERT INTO orders (id, customer_id, total) VALUES (201, 1, 900);
SELECT 'test 2' AS test,
  CASE WHEN (SELECT COUNT(*) FROM orders WHERE customer_id = 1) = 1
       THEN 'PASS' ELSE 'FAIL' END AS result;
ROLLBACK;

SELECT COUNT(*) AS orders_left_after_suite FROM orders;

Test data management

Test data management-এর কয়েকটি কাজের নিয়ম:

• প্রতিটি test নিজের data বানায় (Arrange ধাপে, পর্ব ৪৬); ভাগ করা বড় “seed database”-এ একজন একটি সারি বদলালে দশটি অচেনা test ভাঙে।
• শেষে পরিষ্কার: ROLLBACK; যেখানে তা চলে না (কোড নিজেই commit করে, কয়েকটি connection), সেখানে টেবিল খালি করা বা প্রতিটি test-এ আলাদা schema.
• অনন্য মান আর ছোট builder: একসাথে কয়েকটি test চললে স্থির id ধাক্কা খায়; an_order().paid() ধাঁচের helper শুধু প্রাসঙ্গিক মান দেখায় (পর্ব ৩৩-এর builder pattern).
• আসল গ্রাহকের তথ্য নয়: কৃত্রিম data, বা অন্তত ব্যক্তিগত তথ্য মুছে ফেলা (anonymized) data.

৬ · Contract test — consumer-driven contract আর mock drift

ধরুন একটি mobile app একটি order API ব্যবহার করে। App-এর দল নিজেদের unit test-এ API-র একটি mock বসিয়েছে, যা ফেরত দেয় {"id": 7, "state": "PAID", "total": 450}. ছয় মাস পরে API-এর দল total-এর নাম বদলে amount করল, আর নিজেদের test নতুন নামেই লিখল। দুই দিকেই সবুজ, অথচ production-এ app-এ সব অর্ডারের দাম ফাঁকা। এই অবস্থার নাম mock drift: আসল dependency বদলে গেছে, mock পুরোনো আচরণ নকল করে চলেছে (পর্ব ৪৯-এ এই ঝুঁকির কথা এসেছিল)।

সমাধানের নাম contract test, আর তার জনপ্রিয় রূপ consumer-driven contract: যে পক্ষ API ব্যবহার করে (consumer), সে নিজে লিখে দেয় কোন request পাঠাবে আর response-এর কোন অংশ পড়বে; provider সেই সব চুক্তি নিজের build-এ যাচাই করে — একে বলে provider verification. ধারণাটি Ian Robinson-এর ২০০৬ সালের একটি প্রবন্ধের সাথে যুক্ত; architecture-এর দিক থেকে আলোচনা System Design কোর্সের Microservices পর্বের অংশ ৯-এ। সবচেয়ে পরিচিত tool Pact (আনুমানিক ২০১৩ থেকে open source), যার “broker” চুক্তিগুলো এক জায়গায় রাখে; একই কাজের অন্য tool-ও আছে, যেমন Java-জগতে Spring Cloud Contract. পর্ব ৩১-এর (Interface আর contract) contract ছিল একটি function-এর চুক্তি; এখানে একই ধারণা network-এর দুই পারে।

নিচের খেলনা প্রোগ্রামে দুটি consumer — mobile app আর courier service — প্রত্যেকে শুধু নিজের পড়া field আর তাদের type লিখেছে। Provider-এর দুটি সংস্করণ যাচাই হচ্ছে:

# Toy consumer-driven contract check (real tools: Pact and similar).
# Each consumer records only the fields it READS and their types.
CONTRACTS = {
    "mobile-app": {"GET /orders/7": {"status": 200,
                   "body": {"id": int, "state": str, "total": int}}},
    "courier":    {"GET /orders/7": {"status": 200,
                   "body": {"id": int, "address": str}}},
}

def provider_v1(req):
    return 200, {"id": 7, "state": "PAID", "total": 450,
                 "address": "Mirpur 10, Dhaka", "items": 3}

def provider_v2(req):   # a developer renamed total -> amount
    return 200, {"id": 7, "state": "PAID", "amount": 450,
                 "address": "Mirpur 10, Dhaka", "items": 3, "eta_min": 40}

def verify(provider):
    ok = True
    for consumer, interactions in CONTRACTS.items():
        for req, exp in interactions.items():
            status, body = provider(req)
            problems = [] if status == exp["status"] else [f"status {status}"]
            for field, typ in exp["body"].items():
                if field not in body:
                    problems.append(f"missing field '{field}'")
                elif not isinstance(body[field], typ):
                    problems.append(f"'{field}' is not {typ.__name__}")
            ok = ok and not problems
            print(f"  {consumer:<11}{req}: " + ("PASS" if not problems else "FAIL " + "; ".join(problems)))
    return ok

for name, prov in [("v1", provider_v1), ("v2", provider_v2)]:
    print(f"provider {name}:")
    print("  can deploy?", "yes" if verify(prov) else "NO - a consumer would break")

provider v1:
  mobile-app GET /orders/7: PASS
  courier    GET /orders/7: PASS
  can deploy? yes
provider v2:
  mobile-app GET /orders/7: FAIL missing field 'total'
  courier    GET /orders/7: PASS
  can deploy? NO - a consumer would break

এবার পুরো চক্রটি — consumer-এর test থেকে provider-এর deploy পর্যন্ত — ধাপে ধাপে:

৭ · End-to-end আর UI test — page object, আর কেন অল্প

E2E test পুরো system চালায় — আসল browser, আসল backend, আসল (test) database — আর ব্যবহারকারীর মতো ক্লিক আর টাইপ করে। Browser চালানোর পরিচিত tool: Selenium (২০০৪-এ শুরু; এর WebDriver পরে W3C-এর মান হয়), Cypress (২০১০-এর দশকের শেষে জনপ্রিয়), আর Microsoft-এর Playwright (২০২০)। কোনটি “সেরা”, তা বছর বছর বদলায়; নিচের ধারণাগুলো সবগুলোতেই খাটে।

Page object — UI-এর খুঁটিনাটি এক জায়গায়

E2E test-এর প্রধান রক্ষণাবেক্ষণ-খরচ: UI বদলায়। একটি বোতামের লেখা “Pay” থেকে “টাকা দিন” হলো, আর পঞ্চাশটি test-এ সেই বোতাম খোঁজার কোড ভাঙল। Page object pattern (Selenium সম্প্রদায়ে প্রচলিত; Fowler-এর ২০১৩ সালের একটি লেখায় বর্ণিত) প্রতিটি পাতা বা অংশের জন্য একটি class বানায়, যার method-গুলো ব্যবহারকারীর কাজের ভাষায় — payWithCard(), “এই CSS selector-এ ক্লিক” নয়। UI বদলালে শুধু page object বদলায়, test নয়। Playwright-ধাঁচে (লেখার সময়ের API):

// pages/checkout-page.js — the only place that knows the page's details
export class CheckoutPage {
  constructor(page) { this.page = page; }
  async open() { await this.page.goto('/checkout'); }
  async payWithCard(number) {
    await this.page.getByLabel('Card number').fill(number);
    await this.page.getByRole('button', { name: 'Pay' }).click();
  }
  confirmation() { return this.page.getByTestId('order-confirmation'); }
}

// tests/checkout.spec.js — reads like the user's journey
import { test, expect } from '@playwright/test';
import { CheckoutPage } from '../pages/checkout-page.js';

test('paying by card shows an order number', async ({ page }) => {
  const checkout = new CheckoutPage(page);
  await checkout.open();
  await checkout.payWithCard('0000 1111 2222 3333');      // test-only sandbox card
  await expect(checkout.confirmation()).toContainText('Order #');   // waits, no sleep
});

শেষ লাইনে expect(…).toContainText শর্ত মেলা পর্যন্ত একটি সময়সীমার মধ্যে বারবার দেখে — নির্দিষ্ট sleep নেই (কেন জরুরি, অংশ ৮-এ)। আর খোঁজা হচ্ছে getByTestId বা getByRole দিয়ে, CSS class দিয়ে নয়, যা design বদলালেই বদলায়। (async/await-এর ভিত্তি JavaScript · async/await-এ।)

E2E কম রাখার কৌশল

• শুধু সবচেয়ে মূল্যবান যাত্রা: login, খোঁজা, কার্টে যোগ, টাকা দেওয়া — যা ভাঙলে ব্যবসা থামে। প্রতিটি validation বার্তা E2E-তে নয়; সেটি unit বা component test-এ।
• Setup UI দিয়ে নয়: “অর্ডার বাতিল” test করতে প্রথমে UI দিয়ে অর্ডার বানাবেন না; API বা database দিয়ে সরাসরি বানিয়ে শুধু বাতিলের অংশটি UI-তে।
• বাইরের service নকল: আসল payment gateway, SMS — এগুলোর sandbox বা service virtualization (network-এ সাড়া দেওয়া নকল server). নইলে অন্যের downtime আপনার build লাল করবে।
• একটি ভুল, একটি স্তর: E2E-তে একটি bug ধরা পড়লে নিচের স্তরে একটি test লিখুন, যা সেটি ধরত। E2E-এর সংখ্যা না বাড়িয়ে নিরাপত্তা-জাল শক্ত হয়।

৮ · Flaky test — কারণ, শনাক্তকরণ, quarantine আর সমাধান

Flaky test কোড না বদলেও কখনো pass, কখনো fail করে। Google-এর testing blog-এ ২০১৬ সালের একটি লেখায় (John Micco) জানানো হয়েছিল, তাঁদের test run-এর প্রায় ১.৫% flaky ফল দেখাত, আর প্রায় ১৬% test-এ কিছু না কিছু flakiness ছিল — এক প্রতিষ্ঠানের সংখ্যা, অন্যত্র আলাদা হবে, কিন্তু সমস্যাটি যে বড় দলেও বড়, তা বোঝায়।

প্রধান কারণগুলো

গবেষণাও এই তালিকার সাথে মেলে: Qingzhou Luo ও সহকর্মীদের “An Empirical Analysis of Flaky Tests” (FSE ২০১৪) কয়েকটি বড় open-source project-এর flaky test ঠিক করার commit বিশ্লেষণ করে মূল কারণের সবচেয়ে বড় তিনটি ভাগ হিসেবে পেয়েছিল async অপেক্ষা, concurrency আর test-এর ক্রমের ওপর নির্ভরতা। শেষ সারিটি মনে রাখুন: সব flaky test “test-এর দোষ” নয় — কখনো কোডে সত্যিই একটি race আছে, তাই মুছে দেওয়ার আগে কারণ খুঁজুন।

শনাক্তকরণ — আবার চালানোর পরিসংখ্যান

একটি test flaky কি না, তার সবচেয়ে সরল প্রমাণ: একই কোডে বারবার চালিয়ে দুই রকম ফল। নিচের প্রোগ্রামে একটি কাল্পনিক payment callback ৬০ থেকে ২৬০ মিলিসেকেন্ডের মধ্যে আসে (লোড অনুযায়ী)। প্রথম test ঠিক ২০০ মিলিসেকেন্ড ঘুমিয়ে একবার দেখে; দ্বিতীয়টি শর্তের জন্য অপেক্ষা করে। সময়টি নকল — আসলে কেউ ঘুমায় না — আর এলোমেলো দেরি আসে একটি seed-যুক্ত PRNG (mulberry32) থেকে, তাই ফল প্রতিবার একই:

// Flaky-test detector on SIMULATED time (no real waiting). mulberry32 = seeded PRNG.
function mulberry32(a) {
  return () => { a |= 0; a = a + 0x6D2B79F5 | 0; let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const rand = mulberry32(51);
// The system under test: the payment callback arrives after 60..260 ms (varies by load).
const callbackDelay = () => 60 + Math.floor(rand() * 200);

// FLAKY: sleeps a fixed 200 ms, then checks once.
function testSleepThenCheck() {
  const arrivesAt = callbackDelay();
  return arrivesAt <= 200;                      // was the order PAID at t = 200 ms?
}
// FIXED: waits for the condition itself, polling every 10 ms, up to a 2000 ms deadline.
function testWaitForCondition() {
  const arrivesAt = callbackDelay();
  for (let t = 0; t <= 2000; t += 10) if (t >= arrivesAt) return true;
  return false;                                  // only a real hang fails
}

function rerun(test, n) {
  let pass = 0;
  for (let i = 0; i < n; i++) if (test()) pass++;
  const verdict = pass === n ? "stable pass" : pass === 0 ? "stable fail (real bug?)" : "FLAKY";
  console.log(`${test.name.padEnd(21)} ${pass}/${n} passed (${(100 * pass / n).toFixed(0)}%) -> ${verdict}`);
  return pass / n;
}
const p = rerun(testSleepThenCheck, 50);
console.log(`  chance a red run turns green on one retry: ${(100 * p).toFixed(0)}%`);
console.log(`  chance 3 runs in a row all pass: ${(100 * p ** 3).toFixed(0)}%`);
rerun(testWaitForCondition, 50);

testSleepThenCheck    36/50 passed (72%) -> FLAKY
  chance a red run turns green on one retry: 72%
  chance 3 runs in a row all pass: 37%
testWaitForCondition  50/50 passed (100%) -> stable pass

বাস্তবে এই পরিসংখ্যান আসে CI-এর ইতিহাস থেকে: একই commit-এ একবার লাল, একবার সবুজ মানে flaky; অনেক CI platform এমন হিসাব নিজেই দেখায় (platform-ভেদে আলাদা)। নিজে খুঁজতে test-টি লুপে শতবার, এলোমেলো ক্রমে আর কৃত্রিম চাপের মধ্যে চালান।

Quarantine — আর retry-এর ফাঁদ

Flaky test খুঁজে পাওয়ার পরের প্রশ্ন: ঠিক করার আগ পর্যন্ত কী করবেন? দুটি সহজ কিন্তু খারাপ পথ — মুছে ফেলা (যা পাহারা দিত, তা হারাল), আর স্বয়ংক্রিয় retry দিয়ে চুপ করানো (অনুশীলন ১-এ দেখবেন, এক retry-তে মিথ্যা লাল প্রায় শূন্য — এবং ঠিক সেজন্যই কেউ আর কারণ খোঁজে না, আর আসল race-এর bug-ও retry-তে লুকিয়ে যায়)। মাঝের পথ quarantine: test-টি চলতে থাকে আর ফল রেকর্ড হয়, কিন্তু merge আটকায় না — আর সাথে থাকে একজন মালিক, একটি ticket আর একটি সময়সীমা।

# pytest.ini — register a custom marker
[pytest]
markers =
    quarantine: known flaky; owner and ticket in the reason

# test_payment.py
@pytest.mark.quarantine  # owner: Karima, ticket SHOP-412, fix by 2026-11-15
def test_payment_confirmation_appears():
    ...

# CI: the blocking job skips them; a separate non-blocking job runs only them
#   pytest -m "not quarantine"
#   pytest -m quarantine

এখন পুরো রোগনির্ণয় — CI-তে প্রথম লাল থেকে test-টি মূল suite-এ ফেরা পর্যন্ত:

৯ · Suite-এর গতি, parallelism, test environment আর CI

গতি — কেন মিনিট গুরুত্বপূর্ণ

Suite ২ মিনিটে চললে ডেভেলপার ফল দেখেই এগোন; ২০ মিনিটে চললে অন্য কাজে চলে যান, আর commit-এর আগে স্থানীয়ভাবে চালানো ছেড়ে দেন। দ্রুত করার প্রধান উপায়:

• ধীর test খুঁজুন: বেশিরভাগ test runner সবচেয়ে ধীর test-এর তালিকা দেখাতে পারে (যেমন pytest-এর --durations=10). প্রায়ই অল্প কয়েকটি test মোট সময়ের বড় অংশ নেয় — অংশ ২-এ ২০টি E2E নিয়েছিল ৮০%.
• নিচে নামান: একটি E2E যা আসলে একটি হিসাবের নিয়ম যাচাই করে, তাকে unit test-এ নামান।
• ধীর সাজানো ভাগ করুন: container বা browser প্রতিটি test-এ নতুন নয়, একবার; data-র পরিষ্কার rollback দিয়ে।
• Parallelism আর sharding: suite কয়েকটি ভাগে কয়েকটি process বা যন্ত্রে। শর্ত: test-গুলো hermetic — নিজের data, নিজের port, ভাগ করা অবস্থা নেই। অংশ ৫-এর order-dependent test ঠিক এখানেই ধরা পড়ে।
• শুধু প্রভাবিত test: বড় repository-তে dependency graph দেখে শুধু ছোঁয়া test (পর্ব ১৯-এর affected build); দিনে অন্তত একবার পুরো suite.

Parallelism-এর সীমা: মোট সময় সবচেয়ে লম্বা ভাগের সমান, আর সবচেয়ে লম্বা একক test-এর চেয়ে কম কখনো নয়। অংশ ২-এর ice-cream cone ৮টি যন্ত্রেও ১২.৬ মিনিট — ৮ গুণ যন্ত্রের খরচে।

Test environment

একটি test environment হলো যন্ত্র, software-এর সংস্করণ, config আর data-র পুরো সমষ্টি। সাধারণ স্তর: ডেভেলপারের নিজের কম্পিউটার → CI-এর ক্ষণস্থায়ী পরিবেশ (প্রতিটি run নতুন করে তৈরি) → staging (production-এর যতটা কাছাকাছি সম্ভব) → production. দুটি নীতি:

• ক্ষণস্থায়ী আর পুনরুৎপাদনযোগ্য: প্রতিটি test run নিজের নতুন পরিবেশ পায় (container, script দিয়ে তৈরি)। একটি ভাগ করা staging-এ দশটি দলের E2E একসাথে চললে তারা একে অপরের data বদলায় — flaky test-এর কারখানা।
• Production-এর সাথে পার্থক্য সচেতনভাবে: database-এর সংস্করণ, সময়-অঞ্চল, ভাষা-সেটিং, feature flag — যত পার্থক্য, তত “test-এ ঠিক, production-এ ভুল”। কোনগুলো ইচ্ছাকৃত, তার তালিকা রাখুন। পরিবেশ আর deployment pipeline-এর বিস্তারিত পর্ব ৫৯-এ।

CI-তে test — একটি ধাপের ক্রম

CI pipeline সাধারণত দ্রুত আর সস্তা check আগে চালায়, যাতে সবচেয়ে সাধারণ ভুল সবচেয়ে আগে ধরা পড়ে: static check আর unit test (মিনিটখানেক) → narrow integration আর contract test → কয়েকটি E2E smoke test → merge-এর পরে বা রাতে পুরো E2E আর ধীর suite. প্রতিটি ধাপ ব্যর্থ হলে পরেরটি চলে না — “fail fast”. Pipeline-এর নকশা, cache আর CI YAML পর্ব ৫৮-এ।

১০ · AI-এর যুগে — AI-লেখা test, আর test-কৌশলে AI

AI দিয়ে দ্রুত অনেক test লেখানো যায় — আর ঠিক সেখানেই ঝুঁকি। Test-এর সংখ্যা বাড়ে, কিন্তু pyramid-এর আকার, flakiness আর চুক্তির সত্যতা AI নিজে থেকে দেখে না।

AI-এর সাহায্যে test-কৌশল — চেকলিস্ট

• AI-লেখা প্রতিটি নতুন test আগে ভুল কোডে চালিয়ে দেখেছি — সত্যিই fail করে
• নতুন E2E test-এর বদলে নিচের স্তরে একই ঝুঁকি ধরা যায় কি না, ভেবে দেখেছি
• কোনো নির্দিষ্ট সময়ের sleep বা অন্ধ retry নেই; নতুন test লুপে অনেকবার চালিয়েছি
• Mock-এর response আসল API-র নথি বা contract-এর সাথে মিলিয়েছি
• Library-র method আর CLI flag অফিসিয়াল documentation-এ মিলিয়েছি
• Test data কৃত্রিম; prompt-এ কোনো secret বা ব্যক্তিগত তথ্য পাঠাইনি
• AI-এর দেওয়া Git command (reset --hard, push --force) আগে একটি throwaway clone-এ চালিয়েছি