Test double — dummy, stub, fake, spy, mock আর কখন mock নয়

১ · কেন test double — আসল সহযোগী যখন test-এর শত্রু

পর্ব ৪৬-এ unit test-এর গঠন দেখেছেন — Arrange, Act, Assert — আর জেনেছেন একটি ভালো test দ্রুত, একা চলতে পারে এমন আর প্রতিবার একই ফল দেয়। সমস্যা হলো, বাস্তব কোড একা থাকে না। একটি কাল্পনিক অনলাইন বাজার app-এর OrderService order নিতে গিয়ে payment gateway-তে টাকা কাটে, database-এ order লেখে, ক্রেতাকে SMS পাঠায় আর ঘড়ি দেখে ঠিক করে আজকের delivery সম্ভব কি না। যে কোডটি পরীক্ষা করা হচ্ছে, তাকে বলা হয় SUT (system under test); আর যাদের সে ডাকে, তারা তার সহযোগী বা collaborator.

Unit test-এ আসল সহযোগী ব্যবহার করলে চার ধরনের সমস্যা হয়:

এর ওপর আছে আরেকটি কষ্ট: কিছু অবস্থা আসল সহযোগী দিয়ে তৈরিই করা কঠিন। “Payment gateway ৩০ সেকেন্ড পরে timeout দিলে কী হবে?” বা “রাত ১১টা ৫৯-এ order এলে delivery কোন দিনের?” — এগুলো test করতে আসল gateway-কে ধীর করা বা রাত জেগে বসে থাকা চলে না।

Test double বসানো যায় তখনই, যখন SUT তার সহযোগী বাইরে থেকে নেয়। পর্ব ৩৭-এ দেখেছেন, constructor injection থাকলে test-এ FakeMailer দেওয়া এক লাইনের কাজ; আর পর্ব ২৮-এর dependency inversion বলেছিল, policy নির্ভর করবে নিজের ভাষায় লেখা ছোট চুক্তির ওপর — সেই চুক্তি মানলেই যেকোনো double বসে যায়। যে কোডে SmtpMailer() ভেতরে বানানো, সেখানে double বসাতে হয় জোর করে (patch দিয়ে, অংশ ৫-এ), আর পর্ব ৪৩-এ যে seam-এর কথা বলা হয়েছিল, তা খুঁজতে হয়।

২ · Meszaros-এর পাঁচ double — সুনির্দিষ্ট সংজ্ঞা

Meszaros দুটি দরকারি শব্দ দেন। SUT তার সহযোগীর কাছ থেকে যা পায় (যেমন gateway-র “declined” উত্তর), তা indirect input — test-এর হাতে সরাসরি নেই, সহযোগীর মাধ্যমে আসে। SUT তার সহযোগীকে যা পাঠায় (যেমন SMS-এর লেখা), তা indirect output — ফেরত মানে দেখা যায় না, সহযোগীর কাছে যায়। পাঁচটি double-এর পার্থক্য বোঝার চাবি এটিই: কোনটি indirect input নিয়ন্ত্রণ করে, কোনটি indirect output দেখে।

নিচের কোডে একই OrderService-এর জন্য পাঁচটি double পাশাপাশি। place() gateway-তে টাকা কাটে; উত্তর "ok" হলে order রাখে আর SMS পাঠায়। Constructor একটি audit logger-ও চায়, যা শুধু refund()-এ লাগে — dummy-র জন্য আদর্শ জায়গা।

import unittest, unittest.mock as mock
class OrderService:                    # SUT: the code under test
    def __init__(self, gateway, sms, repo, audit):
        self.gateway, self.sms, self.repo, self.audit = gateway, sms, repo, audit
    def place(self, oid, phone, amount):
        if self.gateway.charge(oid, amount) != "ok": return "declined"
        self.repo.save(oid, amount)
        self.sms.send(phone, f"Order {oid} paid {amount} Tk")
        return "paid"
    def refund(self, oid): self.audit.log("refund " + oid)   # audit: only here
class StubGateway:                     # stub: canned answer to the SUT
    def __init__(self, answer): self.answer = answer
    def charge(self, oid, amount): return self.answer
class SpySms:                          # spy: records calls for later checks
    def __init__(self): self.sent = []
    def send(self, phone, text): self.sent.append((phone, text))
class InMemoryRepo:                    # fake: works, but keeps rows in memory
    def __init__(self): self.rows = {}
    def save(self, oid, amount): self.rows[oid] = amount
def svc(answer="ok", sms=None, repo=None, audit=object()):   # audit: a dummy
    return OrderService(StubGateway(answer), sms or SpySms(), repo or InMemoryRepo(), audit)
class T(unittest.TestCase):
    def test_1_dummy(self): self.assertEqual(svc().place("A1", "01700000000", 500), "paid")
    def test_2_stub(self):  self.assertEqual(svc("declined").place("A2", "01700000000", 500), "declined")
    def test_3_spy(self):
        s = SpySms(); svc(sms=s).place("A3", "01700000000", 250)
        self.assertEqual(s.sent, [("01700000000", "Order A3 paid 250 Tk")])
    def test_4_mock(self):
        m = mock.Mock(spec=["send"]); svc(sms=m).place("A4", "01800000000", 90)
        m.send.assert_called_once_with("01800000000", "Order A4 paid 90 Tk")
    def test_5_fake(self):
        r = InMemoryRepo(); svc(repo=r).place("A5", "01700000000", 700)
        self.assertEqual(r.rows, {"A5": 700})
for name in sorted(n for n in dir(T) if n.startswith("test_")):
    res = unittest.TestResult(); T(name).run(res); print(name, "ok" if res.wasSuccessful() else "FAIL")

test_1_dummy ok
test_2_stub ok
test_3_spy ok
test_4_mock ok
test_5_fake ok

৩ · কোন dependency-তে কোন double

পাঁচটি সংজ্ঞা মুখস্থ করার চেয়ে বেশি কাজের হলো প্রতিটি সহযোগীর সামনে দুটি প্রশ্ন করা: (১) এই test-এ সহযোগীটি কি আদৌ ব্যবহার হয়? (২) এটি SUT-কে কিছু দেয় (indirect input), না SUT এর কাছে কিছু পাঠায় যা যাচাই করতে হবে (indirect output), না দুটিই অনেকবার করে? নিচের stepper-এ কাল্পনিক অনলাইন বাজারের OrderService-এর পাঁচটি সহযোগী একে একে বিচার করা হলো।

৪ · State বনাম behaviour verification — classicist আর mockist

একটি test পাস-ফেল ঠিক করে দুই উপায়ে। State verification-এ test কাজ শেষে দেখে কী হলো — ফেরত মান, SUT-এর অবস্থা, বা fake-এর ভেতরের অবস্থা: “order-টি repository-তে ৭০০ টাকায় আছে।” Behaviour verification-এ (একে interaction testing-ও বলা হয়) test দেখে কীভাবে হলো — SUT তার সহযোগীদের কোন method, কোন argument-এ, কতবার ডাকল: “repo.save("A5", 700) ঠিক একবার ডাকা হয়েছে।”

Martin Fowler তাঁর “Mocks Aren't Stubs” প্রবন্ধে (২০০৭ সালের হালনাগাদ রূপ বহুল উদ্ধৃত) এই দুই ধরনের সাথে দুটি ধারার নাম যুক্ত করেন। Classicist ধারা (কখনো Detroit বা Chicago school বলা হয়, Kent Beck-দের প্রথম দিকের XP কাজের সূত্রে) সম্ভব হলে আসল object ব্যবহার করে, অসুবিধাজনক সহযোগীতে stub বা fake, আর বেশিরভাগ যাচাই করে ফল দেখে। Mockist ধারা (London school নামে পরিচিত; Steve Freeman ও Nat Pryce-এর Growing Object-Oriented Software, Guided by Tests, ২০০৯, এর বহুল পরিচিত বই) প্রতিটি আকর্ষণীয় সহযোগীকে mock দিয়ে বদলায় আর object-গুলোর পারস্পরিক বার্তা যাচাই করে। এই নামগুলো আর শ্রেণিবিভাগ মোটা দাগের; বাস্তবে অধিকাংশ দল দুটি মিশিয়ে চলে।

দুই পক্ষের সবচেয়ে ভালো যুক্তি মনে রাখা দরকার। Mockist-রা বলেন, object-oriented নকশার প্রাণ হলো object-গুলোর বার্তা, তাই বার্তাই test-এর বিষয় হওয়া উচিত; আর mock লিখতে গিয়ে সহযোগীর ছোট, ভূমিকাভিত্তিক interface আপনা থেকে বেরিয়ে আসে — Freeman, Pryce ও সহকর্মীদের ২০০৪ সালের “Mock Roles, not Objects” প্রবন্ধের মূল কথা এটিই বলে উল্লেখ করা হয়। Classicist-রা বলেন, ব্যবহারকারী ফল দেখেন, ভেতরের ডাক দেখেন না; তাই ফল-ভিত্তিক test refactoring-এ টেকে, আর mock-ভারী test অনেক সময় implementation-এর হুবহু প্রতিচ্ছবি — অংশ ৭-এ এর একটি চালানো যায় এমন প্রমাণ দেখবেন। একটি ব্যবহারিক মাঝামাঝি নিয়ম অনেক দলে চলে: query (যা উত্তর দেয়) stub করুন, তার ডাক যাচাই করবেন না; command (যা বাইরের জগৎ বদলায় — SMS, email, payment) হলে তার ডাক যাচাই করুন।

৫ · Python-এর unittest.mock — Mock, patch আর autospec

Python 3.3 থেকে standard library-তে unittest.mock আছে (Michael Foord-এর আলাদা mock library থেকে এসেছে)। এর প্রধান জিনিসগুলো:

• Mock: একটি নমনীয় নকল object. এর যেকোনো attribute চাইলে সাথে সাথে আরেকটি Mock তৈরি হয়, আর যেকোনো ডাক মেনে নিয়ে লিখে রাখে।
• MagicMock: Mock-এর মতোই, কিন্তু len(), for, [], with-এর মতো “magic method”-ও আগে থেকে সাজানো। সাধারণ Mock-এ len(m) দিলে TypeError; MagicMock-এ ফল 0.
• return_value: ডাকলে কী ফেরত আসবে — stub-এর কাজ।
• side_effect: ডাকলে একটি exception ছোড়া (ConnectionError("timeout")), একটি তালিকা থেকে ক্রমে একেকটি মান দেওয়া ([1, 2] — তালিকা ফুরালে StopIteration), বা একটি function চালিয়ে argument অনুযায়ী উত্তর দেওয়া।
• যাচাই: call_count, call_args, call_args_list, mock_calls; আর assert_called_once_with, assert_called_with (শুধু শেষ ডাক), assert_any_call, assert_has_calls, assert_not_called.

নিচের stepper-এ একটি Mock লাইন ধরে ধরে কী লিখে রাখে, আর শেষে যাচাই কীভাবে ব্যর্থ হয়, তা দেখুন। সব মান Python ৩.১৪-এ চালিয়ে মেলানো।

1sms = Mock()2sms.send.return_value = "queued"3sms.send("017", "paid")4sms.send("018", "late")5sms.send.assert_called_with("018", "late")6sms.send.assert_called_once_with("018", "late")

Patch — “যেখানে খোঁজা হয়, সেখানে”

SUT যদি সহযোগী constructor-এ না নিয়ে নিজেই import করে ব্যবহার করে, তখন unittest.mock.patch দিয়ে test চলাকালে নামটি সাময়িক বদলানো যায় — একে monkey patching বলে। Python documentation-এ “Where to patch” নামে আলাদা অংশ আছে, কারণ এখানেই প্রায় সবাই একবার ভুল করেন। মূল নিয়ম: patch করুন সেই নামটি, যা SUT চালানোর সময় খোঁজে — যেখানে object-টি সংজ্ঞায়িত, সেখানে নয়। কেন, তা বুঝতে Python-এর import-এর আচরণ দেখুন।

নিচের কোডে দুটি module (types.ModuleType দিয়ে এক file-এর ভেতরে বানানো, যেন Wandbox-এ চালানো যায়) দিয়ে ঠিক এই ঘটনাটি, আর তারপর autospec-এর কাজ। সাধারণ Mock যেকোনো নাম মেনে নেয় — SUT-এ send-এর বদলে sned লিখলেও কোনো error আসে না। create_autospec আসল class দেখে mock বানায়, তাই অস্তিত্বহীন method আর ভুল argument সাথে সাথে ধরা পড়ে।

import sys, types
from unittest import mock

def make_module(name, source):         # stands in for two real files
    mod = types.ModuleType(name); sys.modules[name] = mod
    exec(source, mod.__dict__); return mod

make_module("sms_lib", "def send_sms(phone, text): return 'REAL SMS to ' + phone")
orders = make_module("orders", """
from sms_lib import send_sms           # copies the name into orders
def notify(phone): return send_sms(phone, 'paid')
""")

with mock.patch("sms_lib.send_sms", return_value="fake") as m:
    print("A patch sms_lib.send_sms ->", orders.notify("017"), "| mock called:", m.called)
with mock.patch("orders.send_sms", return_value="fake") as m:
    print("B patch orders.send_sms  ->", orders.notify("017"), "| mock called:", m.called)

class SmsGateway:                      # the real class we depend on
    def send(self, phone, text): ...

loose = mock.Mock()                    # accepts ANY attribute, any args
loose.sned("017", "hi")                # typo in the code under test
print("C plain Mock, typo sned  -> no error, call_count of send =", loose.send.call_count)
strict = mock.create_autospec(SmsGateway, instance=True)
for label, call in [("typo sned ", lambda: strict.sned("017", "hi")),
                    ("missing arg", lambda: strict.send("017"))]:
    try: call(); print("D autospec,", label, "-> no error")
    except (AttributeError, TypeError) as e: print("D autospec,", label, "->", type(e).__name__ + ":", e)

A patch sms_lib.send_sms -> REAL SMS to 017 | mock called: False
B patch orders.send_sms  -> fake | mock called: True
C plain Mock, typo sned  -> no error, call_count of send = 0
D autospec, typo sned  -> AttributeError: Mock object has no attribute 'sned'
D autospec, missing arg -> TypeError: missing a required argument: 'text'

৬ · JavaScript-এ double, fake clock — আর সময়, random ও network

JavaScript-এ object আর function হালকা, তাই অনেক সময় library ছাড়াই double লেখা যায়: একটি object literal-ই stub, একটি function যা নিজের ডাক একটি array-তে রাখে সেটিই spy. Test framework-গুলো এর জন্য তৈরি সরঞ্জামও দেয় — লেখার সময়ে যেমন Jest-এ jest.fn() (ডাক লিখে রাখে, mockReturnValue দিয়ে উত্তর ঠিক করা যায়) আর jest.useFakeTimers(), Sinon.JS-এ sinon.spy, sinon.stub, sinon.useFakeTimers, আর Node.js-এর নিজস্ব node:test runner-এ mock.fn() ও timer mock-এর ব্যবস্থা। খুঁটিনাটি API version-ভেদে বদলায়, তাই আপনার version-এর documentation দেখে নিন। ভেতরের ভাবনা বুঝতে নিচে হাতে লেখা spy আর fake clock.

কাল্পনিক একটি কোচিং সেন্টারের reminder app-এ ReminderScheduler কয়েক মিনিট পরে SMS পাঠায়। আসল setTimeout দিয়ে test করলে ৬০ মিনিটের reminder-এর জন্য ৬০ মিনিট অপেক্ষা! সমাধান: scheduler ঘড়ি আর sender দুটিই constructor-এ পায় (পর্ব ৩৭), আর test দেয় একটি fake clock, যার সময় test নিজে এগিয়ে দেয়।

// Fake clock + hand-written spy: test a reminder scheduler with no real waiting.
class FakeClock {
  constructor(start) { this.t = start; this.timers = []; }
  now() { return this.t; }
  setTimeout(fn, ms) { this.timers.push({ at: this.t + ms, fn }); }
  advance(ms) {                                  // jump forward, fire due timers in order
    const end = this.t + ms;
    this.timers.sort((a, b) => a.at - b.at);
    while (this.timers.length && this.timers[0].at <= end) {
      const next = this.timers.shift(); this.t = next.at; next.fn();
    }
    this.t = end;
  }
}
class ReminderScheduler {                        // SUT: gets clock and sender injected
  constructor(clock, send) { this.clock = clock; this.send = send; }
  remind(phone, text, minutes) {
    this.clock.setTimeout(() => this.send(phone, text, this.clock.now()), minutes * 60000);
  }
}
function makeSpy() {                             // records every call
  const spy = (...args) => spy.calls.push(args); spy.calls = []; return spy;
}
const clock = new FakeClock(0), spy = makeSpy();
const s = new ReminderScheduler(clock, spy);
s.remind("01700000000", "class at 5pm", 60);
s.remind("01800000000", "fee due", 10);
clock.advance(30 * 60000);
console.log("after 30 min:", spy.calls.length, "call(s)", JSON.stringify(spy.calls));
clock.advance(30 * 60000);
console.log("after 60 min:", spy.calls.length, "call(s), last at minute", spy.calls[1][2] / 60000);
console.log("pending timers:", clock.timers.length, "| clock now (min):", clock.now() / 60000);

after 30 min: 1 call(s) [["01800000000","fee due",600000]]
after 60 min: 2 call(s), last at minute 60
pending timers: 0 | clock now (min): 60

সময়, random আর network — তিনটি চেনা উৎস

৭ · কখন mock নয় — ভঙ্গুর test, নিজের নয় এমন API আর mock drift

Mock শক্তিশালী, আর শক্তিশালী জিনিসের অপব্যবহারও সহজ। তিনটি নিয়ম বহু দলে চলে:

1. যা আপনার নয়, তা mock করবেন না — ইংরেজিতে “don't mock what you don't own”. Freeman ও Pryce-এর লেখায় বহুল পরিচিত এই উপদেশ: একটি payment SDK বা cloud SDK-র class সরাসরি mock করলে আপনি তার আচরণ অনুমান করে লিখছেন — আর SDK-র পরের version বদলালে আপনার mock জানবে না। এর বদলে নিজের ভাষায় একটি ছোট interface বানান (PaymentGateway.charge(order, amount)), তার পেছনে SDK-কে একটি adapter-এ মুড়ে দিন (পর্ব ৩৪) — পর্ব ৪০-এর port আর adapter. তারপর নিজের interface-কে mock বা fake করুন, আর adapter-টিকে আসল (বা sandbox) service-এর বিপরীতে অল্প কয়েকটি integration test-এ যাচাই করুন।
2. Value mock করবেন না। টাকার পরিমাণ, তারিখ, একটি Item("rice", 80) — এগুলো value object, বানানো সহজ, আচরণ স্থির। এদের mock বানালে test পড়া কঠিন হয় আর আসল হিসাবের ভুল লুকায়। নিজের ছোট pure function বা হিসাবের class-ও সাধারণত আসলটিই ব্যবহার করুন।
3. প্রতিটি ভেতরের ডাক যাচাই করবেন না। যত বেশি ডাক যাচাই, test তত বেশি implementation-এর সাথে বাঁধা। একে বলে over-mocking: আচরণ না বদলানো refactoring-এও test লাল, অথচ আসল bug-এ হয়তো সবুজ।

নিচের কোডে over-mocking-এর একটি পরিষ্কার প্রমাণ। একটি কাল্পনিক মুদি-দোকানের cart-এর মোট দাম আগে প্রতিটি পণ্যের দাম আলাদা খুঁজত (CartV1); refactoring-এর পর একবারে সব দাম আনে (CartV2) — ফল হুবহু এক। দুটি test দুই version-এর ওপর চালানো হলো।

from unittest import mock

class CartV1:                              # one price lookup per item
    def __init__(self, repo): self.repo = repo
    def total(self, ids): return sum(self.repo.get_price(i) for i in ids)

class CartV2:                              # refactor: one batch lookup, same result
    def __init__(self, repo): self.repo = repo
    def total(self, ids): return sum(self.repo.get_prices(ids).values())

class FakePriceRepo:                       # fake: in-memory, supports both methods
    def __init__(self, prices): self.prices = prices
    def get_price(self, i): return self.prices[i]
    def get_prices(self, ids): return {i: self.prices[i] for i in ids}

def test_mock_heavy(Cart):                 # pins HOW the code talks to repo
    repo = mock.Mock()
    repo.get_price.side_effect = {"rice": 80, "dal": 120}.get
    assert Cart(repo).total(["rice", "dal"]) == 200
    repo.get_price.assert_has_calls([mock.call("rice"), mock.call("dal")])

def test_state_based(Cart):                # checks only WHAT comes out
    repo = FakePriceRepo({"rice": 80, "dal": 120})
    assert Cart(repo).total(["rice", "dal"]) == 200

for Cart in (CartV1, CartV2):
    for test in (test_mock_heavy, test_state_based):
        try: test(Cart); result = "PASS"
        except Exception as e: result = f"FAIL ({type(e).__name__}: {e})"
        print(f"{Cart.__name__} {test.__name__:16} {result}")

CartV1 test_mock_heavy  PASS
CartV1 test_state_based PASS
CartV2 test_mock_heavy  FAIL (TypeError: 'Mock' object is not iterable)
CartV2 test_state_based PASS

Mock drift আর contract test

উল্টো বিপদও আছে। ধরুন, payment adapter-এর mock সবসময় "ok" ফেরত দেয়। ছয় মাস পরে আসল gateway-র দল উত্তর বদলে {"status": "SUCCESS"} করল। আপনার সব unit test সবুজ — কারণ mock এখনো পুরোনো পৃথিবীতে বাস করে — আর production-এ প্রতিটি order “declined”. একে বলে mock drift: আসল সহযোগী সরে গেছে, নকলটি সরেনি। প্রতিকার:

• Contract test: একই test-এর সেট আসল adapter (sandbox-এ) আর fake দুটির ওপর চালান — দুটিই একই চুক্তি মানছে কি না। Fake তখন হয়ে ওঠে একটি “যাচাই করা fake”, অর্থাৎ বিশ্বাসযোগ্য। Consumer আর provider দুই দলের মধ্যে চুক্তি পরীক্ষার পদ্ধতি পর্ব ৫১-এ।
• Autospec বা typed interface: নিজের interface-এ method-এর নাম বা argument বদলালে mock-ও সাথে সাথে ভাঙে (অংশ ৫)।
• অল্প কিছু আসল integration test: double-ভিত্তিক হাজার test-এর পাশে আসল database বা sandbox-এর বিপরীতে কয়েকটি, যা চুক্তির বড় বদল ধরে।

৮ · AI-এর যুগে test double

AI-কে “এই class-এর unit test চাই” বললে সে প্রায়ই চোখের পলকে দশটি test দেয় — সবুজ, সুন্দর, আর অনেক সময় অকেজো। Test double-এর ক্ষেত্রে সাধারণ ভুলগুলো:

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

• প্রতিটি test কোডে ইচ্ছা করে একটি bug ঢুকিয়ে চালিয়েছি — অন্তত একটি test লাল হয়েছে
• আচরণ একই রেখে একটি ছোট refactoring করে দেখেছি — test সবুজ থেকেছে
• কোনো assert-এর প্রত্যাশিত মান mock-এর return_value থেকে সরাসরি আসেনি
• নিজের interface-এর mock-এ autospec আছে; third-party SDK সরাসরি mock হয়নি, adapter-এর পেছনে আছে
• Test network বন্ধ রেখে চলে; কোনো সত্যি SMS, email বা payment-এর ডাক যায় না
• সময় আর random-নির্ভর test fake clock বা স্থির seed-এ চলে, পরপর দশবার একই ফল
• Prompt-এ কোনো secret বা গ্রাহকের তথ্য দিইনি; AI-এর দেওয়া API-র নাম official documentation-এ মিলিয়েছি, আর কোডের উৎস বা licence নিয়ে সন্দেহ হলে যাচাই করেছি