Unit test — Arrange-Act-Assert, assertion, fixture আর ভালো test-এর গুণ

১ · “Unit” আসলে কী — function, class, না একটি আচরণ?

পর্ব ৪৫-এ (Testing-এর মৌলিক) আপনি test-এর স্তরগুলো দেখেছেন: unit, integration, system আর acceptance. এই পর্বে আমরা সবচেয়ে নিচের আর সবচেয়ে বেশি সংখ্যায় লেখা স্তরটিতে নামব — unit test. সংজ্ঞাটি শুনতে সহজ: কোডের একটি ছোট অংশ একা একা ঠিক কাজ করে কি না, তার স্বয়ংক্রিয় যাচাই। কিন্তু “ছোট অংশ” কতটুকু — এই প্রশ্নে অভিজ্ঞ প্রকৌশলীরাও একমত নন।

দুই ধারা: London বনাম Detroit (Chicago)

Martin Fowler তাঁর ২০০৭ সালের প্রবন্ধ “Mocks Aren't Stubs”-এ দুটি ধারার নাম দেন classicist আর mockist. পরে এরা জায়গার নামেও পরিচিত হয়: Kent Beck-এর মূল XP দলের কাজ যুক্তরাষ্ট্রের Detroit-এ একটি গাড়ি কোম্পানির প্রকল্পে হয়েছিল বলে classicist ধারাকে বলা হয় Detroit (কেউ কেউ বলেন Chicago) school; আর লন্ডনের XP সম্প্রদায় থেকে আসা, Steve Freeman ও Nat Pryce-এর Growing Object-Oriented Software, Guided by Tests (২০০৯) বইয়ে বিস্তারিত হওয়া ধারাকে বলা হয় London school. নামগুলো প্রচলিত ডাকনাম; কোনো আনুষ্ঠানিক মানদণ্ড নয়।

এই দুই রকম test-এর জন্য Jay Fields দুটি সহজ নাম প্রস্তাব করেন, আর Fowler ২০১৪ সালের একটি লেখায় সেগুলো জনপ্রিয় করেন বলে জানা যায়: solitary test (পরীক্ষাধীন class একা, সহযোগীরা নকল) আর sociable test (আসল সহযোগীসহ)। Test double-এর প্রকারভেদ — dummy, stub, fake, spy আর mock — আর কখন mock করা উচিত নয়, তা পর্ব ৪৯-এর (Test double) বিষয়; এখানে শুধু মনে রাখুন যে দুটি ধারাই বৈধ, আর বেশিরভাগ দল দুটোর মিশ্রণ ব্যবহার করে।

এই পর্বের Python উদাহরণগুলো standard library-র unittest দিয়ে, কারণ এটি কিছু install না করেই চলে আর xUnit-এর ধারণাগুলো সরাসরি দেখায়। বাস্তবে Python দলগুলো প্রায়ই pytest ব্যবহার করে; তার খুঁটিনাটি পাবেন Python কোর্সের testing পর্বে, আর JavaScript-এর Vitest/Jest পাবেন JavaScript কোর্সের testing পর্বে. এখানে আমরা ভাষা-নিরপেক্ষ নীতিগুলো দেখব — যেগুলো যেকোনো framework-এ একই।

২ · Arrange–Act–Assert — একটি test-এর তিনটি অংশ

বিয়েবাড়ির রান্নার একটি ছোট পরীক্ষা ভাবুন। বাবুর্চি নতুন মসলার মিশ্রণ চেখে দেখবেন। প্রথমে তিনি এক বাটি ভাত আর এক চামচ মাংস আলাদা করে সাজান (প্রস্তুতি), তারপর মসলা মেশান (একটি কাজ), শেষে চেখে বলেন “লবণ ঠিক আছে” বা “কম হয়েছে” (যাচাই)। তিনি একই সাথে তিনটি মসলা বদলান না — তাহলে স্বাদ খারাপ হলে বোঝা যেত না কোনটির দোষ।

প্রায় প্রতিটি ভালো unit test এই তিন ভাগে লেখা যায়। নামটি Arrange-Act-Assert, সংক্ষেপে AAA; Bill Wake প্রায় ২০০১ সালে এই নাম দেন বলে সাধারণত উল্লেখ করা হয়, যদিও ধারণাটি তার আগেও প্রচলিত ছিল।

• Arrange: পরীক্ষাধীন object আর input তৈরি। এটিই সবচেয়ে লম্বা হতে পারে; বারবার একই জিনিস লাগলে fixture-এ সরান (অংশ ৫)।
• Act: যে আচরণ যাচাই করছেন, সেটি একবার ডাকা। দুটি Act মানে সাধারণত দুটি test লুকিয়ে আছে।
• Assert: ফল প্রত্যাশার সাথে মেলানো। এখানে একাধিক assertion থাকতে পারে, যদি সবগুলো একই আচরণের দিক হয় (যেমন ফেরত দেওয়া রসিদের মোট আর আইটেম সংখ্যা)।

আচরণের ভাষায় একই কাঠামোর নাম Given–When–Then: Given (এই অবস্থা দেওয়া আছে), When (এই ঘটনা ঘটলে), Then (এই ফল হওয়া উচিত)। পর্ব ২২-এ (Use case আর user story) আপনি এটি acceptance criteria লিখতে দেখেছেন; আর পর্ব ৪৮-এ (TDD আর BDD) এটি কীভাবে চালানো যায় এমন specification হয়, তা দেখবেন। Unit test-এ সাধারণত AAA বলা হয়, কারণ ভাষাটি কোডের কাছাকাছি।

এবার একটি test শূন্য থেকে লিখি। কাল্পনিক একটি কুরিয়ার সার্ভিসের delivery fee-র নিয়ম: শহরের ভেতরে প্রথম ১ কেজি ৬০ টাকা, প্রতি বাড়তি (বা আংশিক) কেজি ১৫ টাকা; শহরের বাইরে প্রথম কেজি ১২০ টাকা, প্রতি বাড়তি কেজি ২৫ টাকা। ২.৫ কেজি শহরের বাইরে গেলে ওজন ওপরের দিকে ৩ কেজি ধরা হয়, তাই fee = ১২০ + ২৫ × ২ = ১৭০ টাকা।

1def test_fee_outside_part_kg_rounds_up(self):2    # Arrange3    weight, zone = 2.5, "outside"4    # Act5    result = self.calc.fee(weight, zone)6    # Assert7    self.assertEqual(result, 170)

৩ · ভালো test-এর গুণ — FIRST, এক আচরণ, ভালো নাম, logic নয়

Test-ও কোড, আর খারাপ test খারাপ কোডের মতোই বোঝা। দলের কাছে test-এর মূল্য একটাই: লাল হলে বিশ্বাস করা যায় যে কিছু সত্যিই ভেঙেছে, সবুজ হলে বিশ্বাস করা যায় যে আচরণটি ঠিক আছে। এই বিশ্বাস তৈরি হয় কয়েকটি গুণ থেকে। জনপ্রিয় সংক্ষেপটি FIRST; এটি Brett Schuchert ও Tim Ottinger-এর নামে প্রচলিত, আর Robert C. Martin-এর Clean Code (২০০৮) বইয়ের test অধ্যায়ে ব্যাপক পরিচিতি পায় — অক্ষরগুলোর ব্যাখ্যা উৎসভেদে সামান্য আলাদা।

এক test-এ এক আচরণ

“এক test-এ একটি assertion” নিয়মটি প্রায়ই শোনা যায়, কিন্তু আক্ষরিকভাবে মানলে অপ্রয়োজনীয় কষ্ট। আসল নিয়মটি হলো এক test-এ একটি আচরণ — একটি কারণে ব্যর্থ হওয়া উচিত। “রসিদের মোট ঠিক” আর “রসিদে প্রতিটি আইটেম আছে” একই আচরণের দুটি দিক হলে এক test-এ থাকতে পারে; কিন্তু “মোট ঠিক” আর “ঋণাত্মক ওজনে error” দুটি ভিন্ন আচরণ — আলাদা test. দুটি এক test-এ থাকলে প্রথমটি ব্যর্থ হলে দ্বিতীয়টি চলেই না, আর নাম দিয়ে বোঝানো যায় না কী ভাঙল।

নাম — test-এর নামই প্রথম ব্যর্থতার বার্তা

CI-র লাল তালিকায় আপনি প্রথমে শুধু নামগুলো দেখবেন। test1 বা test_fee কিছুই বলে না। পর্ব ৪১-এর (Clean code) নামের নীতিগুলো test-এ আরও কড়াভাবে খাটে। প্রচলিত কয়েকটি ধরন:

কোন ধরন বেছে নেবেন, তার চেয়ে জরুরি হলো পুরো project-এ একটি ধরন মানা, আর নামে আচরণ লেখা, method-এর নাম নয়। test_calculate নয়, test_fee_unknown_zone_raises.

Test-এ logic নয়

Test-এর ভেতরে if, for দিয়ে হিসাব, বা প্রত্যাশিত মান বের করতে কোডের সূত্রই আবার লেখা — এটি সবচেয়ে প্রচলিত আর সবচেয়ে বিপজ্জনক ভুলগুলোর একটি। নিচের test দেখুন (চালানোর জন্য নয়):

def test_fee_many_weights(self):
    for w in [0.5, 1.2, 3, 7.9]:
        if w <= 1:
            expected = 60
        else:
            expected = 60 + 15 * (math.ceil(w) - 1)   # the formula again!
        self.assertEqual(self.calc.fee(w, "city"), expected)

সমস্যা তিনটি। প্রথমত, প্রত্যাশা কোডের সূত্র থেকেই আসছে, তাই সূত্রে ভুল থাকলে test-ও সেই ভুলকে “ঠিক” বলবে — test আর কোড একই কথা দুবার বলছে। দ্বিতীয়ত, test-এর if নিজেই ভুল হতে পারে, আর test-এর test কেউ লেখে না। তৃতীয়ত, loop-এ প্রথম ব্যর্থতায় বাকি মানগুলো আর যাচাই হয় না। সমাধান: প্রত্যাশিত মান হাতে হিসাব করা সংখ্যা হিসেবে একটি টেবিলে লিখুন, আর টেবিলটি parameterized test দিয়ে চালান (অংশ ৫)। Test হওয়া উচিত মুদি দোকানের হিসাবের খাতার পাতার মতো — প্রতিটি লাইনে “এই মাল, এই দাম”।

৪ · Assertion — কোন যাচাইয়ে কোন হাতিয়ার

Test-এর assertion হলো রায় দেওয়ার মুহূর্ত। প্রতিটি framework অনেকগুলো assertion দেয়, আর ঠিকটি বেছে নিলে ব্যর্থতার বার্তা অনেক স্পষ্ট হয়। যেমন assertTrue(a == b) ব্যর্থ হলে শুধু বলে False is not true; কিন্তু assertEqual(a, b) বলে 170 != 160, আর list হলে কোন ঘরে পার্থক্য তাও দেখায়।

Exception যাচাই — ভুল input-এ ঠিকভাবে ব্যর্থ হওয়া

একটি function-এর চুক্তির অর্ধেকটা হলো “ভুল input-এ কী হবে।” শূন্য ওজনে fee চাইলে ValueError ওঠা উচিত — এটাও একটি আচরণ, তাই এর জন্যও test লাগে। দুটি সতর্কতা: (১) শুধু exception-এর ধরন নয়, দরকার হলে বার্তাটিও মেলান (assertRaisesRegex, pytest-এর match=), নইলে অন্য কোনো কারণে ওঠা একই ধরনের exception-ও test পাশ করিয়ে দেবে। (২) with block-এর ভেতরে শুধু সেই একটি লাইন রাখুন যেটি exception তোলার কথা; Arrange অংশ ভেতরে রাখলে সেখানে ওঠা exception-ও “সফল” ধরা হবে। Jest-এ toThrow-কে function দিতে হয় (() => f()), ফল নয় — expect(f()).toThrow() লিখলে exception test-এর বাইরেই উঠে যায়।

Floating point — 0.1 + 0.2 কেন 0.3 নয়

কম্পিউটার দশমিক সংখ্যা সাধারণত IEEE 754 floating-point আকারে রাখে, যেখানে ভিত্তি ২. দশমিকের ১/১০ ভগ্নাংশটি ২-ভিত্তিতে ঠিক যেমন ১/৩ দশমিকে — অসীম পুনরাবৃত্তি (০.৩৩৩…)। তাই 0.1 আসলে 0.1-এর খুব কাছের একটি সংখ্যা, আর যোগফলে ক্ষুদ্র ভুল জমে: 0.1 + 0.2 হয় 0.30000000000000004. এর মানে test-এ দশমিক ফল হুবহু সমতা দিয়ে মেলানো যায় না; একটি সহনসীমা (tolerance) লাগে:

• assertAlmostEqual(a, b, places=7): round(a - b, 7) == 0 হলে পাশ (default ৭ ঘর)। চাইলে delta=0.01 দিয়ে সরাসরি সীমা দেওয়া যায়।
• pytest.approx(b): default-এ আপেক্ষিক সহনসীমা প্রায় 1e-6 (pytest-এর নথিতে বিস্তারিত; সংস্করণভেদে দেখে নিন)।
• Jest-এর toBeCloseTo(b, digits): |b − a| < 10^(−digits) / 2 হলে পাশ, default digits = 2.

টাকার হিসাবে কিন্তু সহনসীমা দিয়ে লুকানো সমাধান নয়: সেখানে পয়সায় পূর্ণসংখ্যা বা Python-এর decimal.Decimal ব্যবহার করুন, যাতে হিসাবটাই হুবহু হয়। Tolerance দরকার বৈজ্ঞানিক বা পরিমাপের হিসাবে, যেখানে ক্ষুদ্র ভুল স্বাভাবিক। নিচের ছোট harness-টি (৩২ লাইন) Jest-এর মতো test, test.each আর expect নিজেই বানায়, তারপর একটি কাল্পনিক বাজার app-এর বিল ভাগ করার function পরীক্ষা করে:

// A tiny Jest-style harness: test, test.each, expect().toBe / toBeCloseTo / toThrow
function test(name, fn) {
  try { fn(); console.log("PASS " + name); }
  catch (e) { console.log("FAIL " + name + "  -> " + e.message); }
}
test.each = (rows) => (title, fn) => rows.forEach((row) => {
  let i = 0;
  test(title.replace(/%s/g, () => String(row[i++])), () => fn(...row));
});
function expect(actual) {
  return {
    toBe(exp) { if (!Object.is(actual, exp)) throw new Error(`expected ${exp}, got ${actual}`); },
    toBeCloseTo(exp, digits = 2) {   // same rule as Jest: |exp - actual| < 10^-digits / 2
      if (!(Math.abs(exp - actual) < 10 ** -digits / 2)) throw new Error(`expected ~${exp}, got ${actual}`);
    },
    toThrow(part) {
      try { actual(); } catch (e) { if (e.message.includes(part)) return; throw new Error("wrong error: " + e.message); }
      throw new Error("expected a throw, nothing was thrown");
    },
  };
}
// Code under test (fictional bazaar app): split a bill between friends
function splitBill(total, people) {
  if (people < 1) throw new Error("people must be at least 1");
  return total / people;
}
test("0.1 + 0.2 toBe 0.3", () => expect(0.1 + 0.2).toBe(0.3));
test("0.1 + 0.2 toBeCloseTo 0.3", () => expect(0.1 + 0.2).toBeCloseTo(0.3));
test.each([[100, 4, 25], [100, 3, 33.33], [0.3, 3, 0.1]])(
  "splitBill(%s, %s) is about %s", (total, people, share) => expect(splitBill(total, people)).toBeCloseTo(share));
test("splitBill(100, 3) toBe 33.33", () => expect(splitBill(100, 3)).toBe(33.33));
test("splitBill with 0 people throws", () => expect(() => splitBill(500, 0)).toThrow("at least 1"));

FAIL 0.1 + 0.2 toBe 0.3  -> expected 0.3, got 0.30000000000000004
PASS 0.1 + 0.2 toBeCloseTo 0.3
PASS splitBill(100, 4) is about 25
PASS splitBill(100, 3) is about 33.33
PASS splitBill(0.3, 3) is about 0.1
FAIL splitBill(100, 3) toBe 33.33  -> expected 33.33, got 33.333333333333336
PASS splitBill with 0 people throws

Collection — ক্রম জরুরি কি না, আগে ঠিক করুন

একটি function যদি “এই এলাকার সব rider-এর নাম” ফেরত দেয়, আর ক্রম চুক্তির অংশ না হয়, তাহলে assertEqual(result, ["Jamal", "Karim"]) লিখলে test অকারণে ক্রমের ওপর নির্ভর করবে। এমন ক্ষেত্রে assertCountEqual (নাম বিভ্রান্তিকর, কিন্তু কাজ হলো “ক্রম বাদে একই উপাদান, একই সংখ্যায়”) বা সাজিয়ে তুলনা করুন। উল্টোভাবে, যদি ক্রম চুক্তির অংশ হয় (যেমন “সবচেয়ে কাছের rider আগে”), তাহলে ঠিক ক্রমটিই যাচাই করুন। JavaScript-এ array বা object-এর গঠন মেলাতে toBe নয়, toEqual লাগে।

৫ · Fixture আর parameterized test — শুরুর অবস্থা আর অনেক input

প্রতিটি test-এর Arrange অংশে একই কয়েকটি লাইন বারবার এলে সেগুলো এক জায়গায় সরানো যায়। Test শুরুর আগের এই নির্দিষ্ট অবস্থার নাম test fixture — যেমন ক্রিকেট ম্যাচের আগে প্রতিবার পিচ রোল করা আর দাগ টানা। xUnit-এ fixture তৈরির জায়গা হলো কয়েকটি বিশেষ method:

• setUp() — প্রতিটি test-এর ঠিক আগে চলে; tearDown() — প্রতিটি test-এর পরে, test ব্যর্থ হলেও (তবে setUp নিজেই ব্যর্থ হলে tearDown চলে না)।
• setUpClass() / tearDownClass() — পুরো class-এর জন্য একবার; ব্যয়বহুল কিন্তু শুধু-পড়ার (read-only) জিনিসের জন্য, যেমন বড় একটি rate table পড়া। এখানে বদলানো যায় এমন object রাখলে test-গুলো একে অপরকে প্রভাবিত করবে (অংশ ৬)।
• addCleanup(fn) — যেখানে কিছু তৈরি হলো, সেখানেই তার পরিষ্কারের কাজ নথিভুক্ত করা; ক্রমটি উল্টো (শেষে যোগ করা আগে চলে)।

নিচের stepper-এ একই class লাইন ধরে চালিয়ে দেখুন — কোন লাইন কখন চলে, আর অস্থায়ী ফোল্ডারে কী থাকে। unittest একটি class-এর test method-গুলো default-এ নামের বর্ণানুক্রমে চালায়, তাই test_a… আগে, test_b… পরে।

1class ReceiptTest(unittest.TestCase):2    @classmethod3    def setUpClass(cls):4        cls.rates = load_rates()      # once5    def setUp(self):6        self.tmp = tempfile.TemporaryDirectory()7        self.calc = FeeCalculator(self.rates)8    def tearDown(self):9        self.tmp.cleanup()10    def test_a_writes_receipt(self):11        save_receipt(self.tmp.name, self.calc.fee(1, "city"))12        self.assertEqual(len(os.listdir(self.tmp.name)), 1)13    def test_b_folder_starts_empty(self):14        self.assertEqual(os.listdir(self.tmp.name), [])15    @classmethod16    def tearDownClass(cls):17        del cls.rates

pytest fixture আর tmp_path

pytest-এ fixture হলো একটি সাধারণ function, যার ওপর @pytest.fixture লেখা; test শুধু parameter-এর নামে সেটি চায়, আর pytest নাম মিলিয়ে দিয়ে দেয় — একধরনের dependency injection. yield-এর পরের অংশটি tearDown-এর কাজ করে। tmp_path হলো pytest-এর নিজস্ব একটি fixture, যা প্রতিটি test-কে একটি নতুন অস্থায়ী ফোল্ডার (pathlib.Path) দেয় — pytest-এর নতুন সংস্করণগুলোতে এটিই সুপারিশকৃত; পুরোনো tmpdir-ও আছে। (চালানোর জন্য নয়, আকার দেখাতে:)

import pytest

@pytest.fixture
def calc():
    c = FeeCalculator()
    yield c                   # the test runs here
    c.close()                 # teardown part

def test_receipt_file_written(calc, tmp_path):
    save_receipt(tmp_path, calc.fee(1, "city"))
    assert (tmp_path / "receipt.txt").read_text() == "fee=60\n"

Test data builder — অপ্রাসঙ্গিক খুঁটিনাটি লুকানো

একটি অর্ডার object-এ যদি বারোটি field থাকে (গ্রাহক, ঠিকানা, ফোন, আইটেম, zone, কুপন…), আর একটি test শুধু zone নিয়ে চিন্তিত, তাহলে বারোটি field-ই test-এ লেখা পাঠকের চোখ সরিয়ে দেয়। Test data builder — Nat Pryce-এর লেখার মাধ্যমে প্রায় ২০০৭ সাল থেকে পরিচিত, আর পর্ব ৩৩-এর builder pattern-এর ছোট আত্মীয় — যুক্তিসংগত default দিয়ে একটি বৈধ object বানায়, আর test শুধু যা প্রাসঙ্গিক তা বদলায়:

def an_order(**changes):
    order = dict(customer="Test Customer", zone="city", weight_kg=1, coupon=None)
    order.update(changes)
    return order

def test_outside_zone_costs_more(self):
    city = self.calc.fee_for(an_order())
    outside = self.calc.fee_for(an_order(zone="outside"))
    self.assertGreater(outside, city)

Parameterized test — এক কাঠামো, অনেক সারি

অংশ ৩-এর loop-ওয়ালা test-এর সঠিক রূপ হলো parameterized test: input আর প্রত্যাশিত ফলের একটি টেবিল, আর প্রতিটি সারি আলাদা test হিসেবে রিপোর্ট হয়। unittest-এ এর জন্য আছে self.subTest(...) (Python 3.4 থেকে) — একটি সারি ব্যর্থ হলেও বাকি সারিগুলো চলে, আর রিপোর্টে কোন সারি ব্যর্থ তা দেখায়। pytest-এ @pytest.mark.parametrize("weight,zone,expected", [...]), আর Jest/Vitest-এ test.each (Jest-এ সংস্করণ ২৩ থেকে আছে বলে জানা যায়)। কোন সারিগুলো বেছে নেবেন — যেমন সীমার ঠিক আগের, ঠিক ওপরের আর ঠিক পরের মান — সেটি পর্ব ৪৭-এর (Test case নকশা) মূল বিষয়: equivalence partitioning আর boundary value.

এবার সব একসাথে: AAA, setUp, subTest দিয়ে টেবিল আর assertRaises. Suite চালানো হয়েছে TextTestRunner(stream=sys.stdout, verbosity=2) দিয়ে, যাতে প্রতিটি test-এর নাম আর ফল দেখা যায়।

import math, sys, unittest
class FeeCalculator:                       # fictional courier: delivery fee in Taka
    RATES = {"city": (60, 15), "outside": (120, 25)}   # (first kg, each extra kg)
    def fee(self, weight_kg, zone):
        if weight_kg <= 0:
            raise ValueError("weight must be positive")
        if zone not in self.RATES:
            raise ValueError(f"unknown zone: {zone}")
        first, extra = self.RATES[zone]
        return first + extra * (math.ceil(weight_kg) - 1)
class FeeCalculatorTest(unittest.TestCase):
    def setUp(self):                       # runs before EVERY test: fresh object
        self.calc = FeeCalculator()
    def test_fee_city_one_kg_is_base_rate(self):
        weight, zone = 1, "city"                  # Arrange
        result = self.calc.fee(weight, zone)      # Act
        self.assertEqual(result, 60)              # Assert
    def test_fee_rounds_part_kg_up(self):
        cases = [(0.5, "city", 60), (1.2, "city", 75),
                 (3, "outside", 170), (2.01, "outside", 170)]
        for weight, zone, expected in cases:
            with self.subTest(weight=weight, zone=zone):
                self.assertEqual(self.calc.fee(weight, zone), expected)
    def test_fee_zero_weight_raises(self):
        with self.assertRaises(ValueError):
            self.calc.fee(0, "city")
    def test_fee_unknown_zone_raises_with_message(self):
        with self.assertRaisesRegex(ValueError, "unknown zone"):
            self.calc.fee(1, "moon")
suite = unittest.defaultTestLoader.loadTestsFromTestCase(FeeCalculatorTest)
unittest.TextTestRunner(stream=sys.stdout, verbosity=2).run(suite)

test_fee_city_one_kg_is_base_rate (__main__.FeeCalculatorTest.test_fee_city_one_kg_is_base_rate) ... ok
test_fee_rounds_part_kg_up (__main__.FeeCalculatorTest.test_fee_rounds_part_kg_up) ... ok
test_fee_unknown_zone_raises_with_message (__main__.FeeCalculatorTest.test_fee_unknown_zone_raises_with_message) ... ok
test_fee_zero_weight_raises (__main__.FeeCalculatorTest.test_fee_zero_weight_raises) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.000s

OK

৬ · Deterministic test — সময়, এলোমেলোতা আর ক্রম

সবচেয়ে সহজে test করা যায় pure function: একই input-এ সবসময় একই output, বাইরের কিছু পড়েও না, বদলায়ও না। fee(2.5, "outside") চিরকাল ১৭০. সমস্যা শুরু হয় যখন কোড চুপচাপ বাইরের জগৎ থেকে কিছু পড়ে — আজকের তারিখ, এলোমেলো সংখ্যা, environment variable, ফাইল, network — বা বাইরে কিছু লেখে (side effect). এগুলো function-এর signature-এ দেখা যায় না, অর্থাৎ hidden dependency. ফলে test আর deterministic থাকে না: কোড না বদলালেও আজ পাশ, কাল ফেল। এমন test-এর নাম flaky test.

কৌশলটি পর্ব ৩৭-এর (Dependency injection আর composition) সরাসরি প্রয়োগ: সময় বা এলোমেলোতা function-এর ভেতরে না পড়ে বাইরে থেকে দিন — মান হিসেবে (today), একটি clock object হিসেবে, বা একটি function হিসেবে (choose). Production-এ আসল ঘড়ি বসবে, test-এ একটি নির্দিষ্ট তারিখ। এলোমেলোতার ক্ষেত্রে আরেকটি পথ হলো নির্দিষ্ট seed-সহ একটি PRNG (random.Random(42)) দেওয়া; তবে seed-নির্ভর নির্দিষ্ট মান assert করলে test PRNG-এর ভেতরের algorithm-এ বাঁধা পড়ে, তাই সম্ভব হলে আচরণের ধর্ম যাচাই করুন (“ফল তালিকার ভেতরেই আছে”)।

নিচের কোডে প্রথম দুটি test লুকানো ঘড়ি আর লুকানো এলোমেলোতা ব্যবহার করে; পরের তিনটি একই আচরণ deterministic উপায়ে যাচাই করে। প্রতিটি test ৩০ বার চালানো হয়েছে, যেন ৩০টি CI run.

import datetime as dt, random, unittest
RIDERS = ["Karim", "Jamal", "Rafiq"]
def is_late_v1(due):                 # hidden clock: reads today's real date
    return dt.date.today() > due
def pick_rider_v1(riders):           # hidden randomness
    return random.choice(riders)
def is_late(due, today):             # the date comes in as a value
    return today > due
def pick_rider(riders, choose):      # the "random" choice comes in as a function
    return choose(riders)
class FlakyTests(unittest.TestCase):
    def test_not_late_v1(self):      # written in 2025, when it passed
        self.assertFalse(is_late_v1(dt.date(2025, 12, 31)))
    def test_pick_rider_v1(self):
        self.assertEqual(pick_rider_v1(RIDERS), "Karim")
class DeterministicTests(unittest.TestCase):
    def test_not_late_on_due_date(self):
        self.assertFalse(is_late(dt.date(2025, 12, 31), today=dt.date(2025, 12, 31)))
    def test_late_one_day_after(self):
        self.assertTrue(is_late(dt.date(2025, 12, 31), today=dt.date(2026, 1, 1)))
    def test_pick_rider_uses_choice(self):
        self.assertEqual(pick_rider(RIDERS, choose=lambda r: r[-1]), "Rafiq")
def run(cls, times):
    for name in unittest.defaultTestLoader.getTestCaseNames(cls):
        passed = 0
        for _ in range(times):
            result = unittest.TestResult()
            cls(name).run(result)
            passed += result.wasSuccessful()
        print(f"{name:28} passed {passed}/{times}")
random.seed(46)                      # fixed only so this page shows the same counts
run(FlakyTests, 30)
run(DeterministicTests, 30)

test_not_late_v1             passed 0/30
test_pick_rider_v1           passed 12/30
test_late_one_day_after      passed 30/30
test_not_late_on_due_date    passed 30/30
test_pick_rider_uses_choice  passed 30/30

ক্রমনির্ভর test — ভাগ করা mutable state

তৃতীয় প্রচলিত উৎস হলো test-গুলোর মধ্যে ভাগ করা, বদলানো যায় এমন অবস্থা: একটি class attribute, module-স্তরের list, global singleton, বা একটি ডেটাবেস টেবিল যা কেউ পরিষ্কার করে না। একটি test তাতে কিছু রেখে যায়, পরেরটি সেটি দেখে অবাক হয়। এর নাম test interdependence, আর এর বৈশিষ্ট্য হলো “একা চালালে পাশ, সবার সাথে চালালে ফেল” (বা উল্টো)। নিচে একই দুটি test দুই ক্রমে চালানো হয়েছে — প্রথমে একটি ভাগ করা cart-এ, তারপর setUp-এ প্রতিবার নতুন cart দিয়ে:

import unittest
class Cart:                                   # fictional grocery app
    def __init__(self): self.items = []
    def add(self, name, price): self.items.append((name, price))
    def total(self): return sum(price for _, price in self.items)
class SharedCartTest(unittest.TestCase):
    cart = Cart()                             # ONE cart shared by every test
    def test_add_item(self):
        self.cart.add("rice", 80)
        self.assertEqual(self.cart.total(), 80)
    def test_new_cart_is_empty(self):
        self.assertEqual(self.cart.total(), 0)
class FreshCartTest(SharedCartTest):          # same two tests ...
    def setUp(self):
        self.cart = Cart()                    # ... but a new cart before EACH test
def run(cls, order):
    SharedCartTest.cart = Cart()              # start every session clean
    result = unittest.TestResult()
    unittest.TestSuite(cls(name) for name in order).run(result)
    failed = [test._testMethodName for test, _ in result.failures]
    print(f"{cls.__name__:14} {' -> '.join(order)}: failed {failed or 'none'}")
A = ["test_new_cart_is_empty", "test_add_item"]
B = ["test_add_item", "test_new_cart_is_empty"]
run(SharedCartTest, A)
run(SharedCartTest, B)
run(FreshCartTest, A)
run(FreshCartTest, B)

SharedCartTest test_new_cart_is_empty -> test_add_item: failed none
SharedCartTest test_add_item -> test_new_cart_is_empty: failed ['test_new_cart_is_empty']
FreshCartTest  test_new_cart_is_empty -> test_add_item: failed none
FreshCartTest  test_add_item -> test_new_cart_is_empty: failed none

৭ · Test smell — যে লক্ষণ দেখে test সন্দেহ করবেন

পর্ব ৪২-এ (Code smell আর refactoring) আপনি production কোডের code smell দেখেছেন। Test কোডেরও নিজস্ব smell আছে — test smell. শব্দটির প্রথম তালিকা Arie van Deursen ও সহকর্মীদের ২০০১ সালের “Refactoring Test Code” গবেষণাপত্রে পাওয়া যায় বলে সাধারণত উল্লেখ করা হয়; পরে Gerard Meszaros-এর xUnit Test Patterns (২০০৭) বইয়ে বিস্তৃত ক্যাটালগ আসে। নিচের ছয়টি সবচেয়ে প্রচলিত:

Fragile test সবচেয়ে ক্ষতিকর, কারণ এটি refactoring-এর মূল প্রতিশ্রুতি ভাঙে — “বাইরের আচরণ না বদলালে test সবুজ থাকবে” (পর্ব ৪২)। নিচের stepper-এ একটি fragile test ধাপে ধাপে সারানো হলো। কাল্পনিক বাজার app-এর receipt(order) একটি রসিদের লেখা বানায়।

৮ · Test সাজানো, ফাইলের নাম আর চালানো

Test runner হাজার ফাইলের ভেতর থেকে test খুঁজে নেয় নামের নিয়ম দেখে — একে বলে test discovery. তাই ফাইল আর function-এর নাম শুধু রুচির বিষয় নয়; ভুল নাম দিলে test চুপচাপ বাদ পড়ে, আর “সব পাশ” দেখে আপনি ভাববেন সব ঠিক।

এগুলো default; প্রতিটি tool-এর configuration-এ বদলানো যায়, আর সংস্করণভেদে খুঁটিনাটি আলাদা হতে পারে — নিজের project-এর নথি দেখুন। ফোল্ডার সাজানোর দুটি প্রচলিত ধরন: (১) কোডের পাশেই test (fee.js আর fee.test.js একই ফোল্ডারে), যা JavaScript-এ সাধারণ; (২) আলাদা tests/ ফোল্ডার, যার ভেতরে কোডের ফোল্ডার-কাঠামোর আয়না (src/courier/fee.py ↔ tests/courier/test_fee.py), যা Python-এ সাধারণ। যেটিই নিন, নিয়মটি হলো: যেকোনো কোড ফাইল দেখে তার test কোথায়, তা অনুমান করা যায়।

প্রতিদিনের কাজে পুরো suite নয়, শুধু প্রাসঙ্গিক অংশ চালানো যায়। নিচের কমান্ডগুলো উদাহরণ (আউটপুট দেখানো হয়নি):

# one test method with unittest
python -m unittest tests.test_fee.FeeCalculatorTest.test_fee_zero_weight_raises
# pytest: only tests whose name matches "zone", stop at first failure
pytest -k zone -x
# Jest: only tests whose name matches a pattern
npx jest -t "splitBill"

আর দলের কাজে test চালানোর আসল জায়গা হলো continuous integration: প্রতিটি push বা pull request-এ একটি pipeline স্বয়ংক্রিয়ভাবে পুরো suite চালায়, আর লাল হলে merge আটকায়। কীভাবে pipeline সাজাবেন, দ্রুত feedback-এর জন্য কোন test আগে চালাবেন — সেটি পর্ব ৫৮-এর (Continuous integration) বিষয়। আর কত ভাগ কোড আপনার test চালায়, সেটি মাপার উপায় (coverage) আর তার সীমাবদ্ধতা পর্ব ৫০-এ (Coverage আর complexity).

৯ · AI-এর যুগে unit test

AI-কে “এই function-এর জন্য unit test লিখে দাও” বললে কয়েক সেকেন্ডে ত্রিশটি test চলে আসে, সবগুলো সবুজ। এটাই বিপদ। সবুজ test মানে শুধু এই যে test আর কোড একে অপরের সাথে মিলছে — কোড ঠিক কি না, তা নয়। AI-এর লেখা test-এ প্রায়ই যা দেখা যায়:

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

• প্রতিটি প্রত্যাশিত মান requirement বা হাতে হিসাব থেকে মিলিয়েছি — কোড চালিয়ে পাওয়া মান কপি করা হয়নি
• কোডে ইচ্ছা করে একটি ভুল (যেমন ceil-এর জায়গায় round) ঢুকিয়ে দেখেছি — অন্তত একটি test লাল হয়েছে
• সময়, random, network বা ফাইল সরাসরি ব্যবহার হয়নি; হলে inject বা অস্থায়ী fixture দিয়ে বদলেছি
• Test-গুলো এলোমেলো ক্রমে আর একা একা চালিয়েও একই ফল পেয়েছি
• প্রতিটি assertion আর framework option অফিসিয়াল নথিতে আছে, আর আমার সংস্করণে কাজ করে
• Test-এর নাম পড়ে বলতে পারি কোন আচরণ ভাঙলে কোনটি লাল হবে
• Prompt-এ কোনো আসল গ্রাহকের তথ্য, password বা API key পাঠাইনি; test ডেটা কাল্পনিক