TDD আর BDD — red-green-refactor আর Given-When-Then

১ · TDD কী — কোডের আগে test কেন

পর্ব ৪৫-এ দেখেছেন test কাকে বলে আর কোন স্তরে কী যাচাই হয়; পর্ব ৪৬-এ শিখেছেন একটি unit test-এর গঠন — Arrange-Act-Assert, assertion আর fixture. আর পর্ব ৪৭-এ দেখেছেন কোন কোন input বেছে নিলে কম test-এ বেশি ভুল ধরা যায়। সেখানে ধরে নেওয়া হয়েছিল, কোড আগে আছে, test পরে আসে। Test-driven development (TDD) এই ক্রম উল্টে দেয়: আগে এমন একটি test লিখুন যা এখন ফেল করে, তারপর ঠিক ততটুকু কোড লিখুন যাতে সেটি পাস করে, তারপর কোড গোছান। তারপর পরের test.

পদ্ধতিটির নাম আর রূপ দাঁড় করান Kent Beck. ১৯৯০-এর দশকের শেষে Extreme Programming (XP)-এর (পর্ব ৫) একটি মূল অনুশীলন ছিল “test-first programming”. পরে Beck তাঁর Test-Driven Development: By Example বইয়ে (Addison-Wesley; ২০০২ সালের শেষ দিকে প্রকাশিত, বইয়ে কপিরাইট সাল ২০০৩ — তাই দুটি সালই উদ্ধৃত হতে দেখবেন) পুরো পদ্ধতিটি উদাহরণসহ লেখেন। বইয়ের প্রথম ভাগে বহু-মুদ্রার একটি Money উদাহরণ ছোট ছোট চক্রে গড়ে ওঠে, আর দ্বিতীয় ভাগে Beck Python-এ একটি xUnit ধরনের test framework নিজেই TDD দিয়ে বানান। Beck নিজে বলেছেন তিনি পদ্ধতিটি “পুনরাবিষ্কার” করেছেন — পুরোনো programming বইয়ে প্রত্যাশিত আউটপুট আগে লিখে রাখার কথা পড়েছিলেন।

Beck-এর দুটি নিয়ম আর “তিন সূত্র”

বইয়ের ভূমিকায় Beck পুরো পদ্ধতিকে দুটি নিয়মে বাঁধেন:

1. নতুন কোড লিখুন কেবল তখনই, যখন একটি স্বয়ংক্রিয় test আগে ফেল করেছে।
2. Duplication দূর করুন। — test আর কোডের মধ্যে, কোডের ভেতরে, যেখানেই হোক।

পরে Robert C. Martin (যাঁকে অনেকে “Uncle Bob” নামে চেনেন) একই কথাকে আরও কড়া করে তিনটি “সূত্রে” লেখেন, যা তাঁর ২০০০-এর দশকের লেখা আর Clean Code (২০০৮) বইয়ের test-বিষয়ক অধ্যায়ে পাওয়া যায় — ভাষা জায়গাভেদে একটু আলাদা। এগুলোকে বলা হয় three laws of TDD:

1. একটি ব্যর্থ unit test না লিখে কোনো production কোড লেখা যাবে না।
2. ফেল করার জন্য যতটুকু দরকার, তার বেশি test লেখা যাবে না — আর compile না হওয়াও ফেল।
3. বর্তমান ব্যর্থ test-টি পাস করানোর জন্য যতটুকু দরকার, তার বেশি production কোড লেখা যাবে না।

তিন সূত্র মানলে চক্র হয় খুব ছোট — কয়েক সেকেন্ড থেকে কয়েক মিনিট। Beck নিজে ধাপের মাপ অবস্থা বুঝে ছোট-বড় করার কথা বলেন (অংশ ২), তবে অভ্যাস গড়ার সময়ে কড়া রূপটি কাজের।

২ · Red → green → refactor — চক্রটি খুঁটিয়ে

TDD-র হৃৎস্পন্দন তিন রঙের একটি চক্র, যার নাম red-green-refactor. রং দুটি এসেছে test runner-এর পুরোনো progress bar থেকে — ফেল করলে লাল, সব পাস করলে সবুজ।

তিনটি ধাপ, প্রতিটির নিজের নিয়ম

• Red — একটি ছোট ব্যর্থ test: test list থেকে একটি item নিয়ে test লিখুন, চালান, আর লাল দেখুন। লাল দেখা প্রমাণ করে test-টি আদৌ ফেল করতে পারে। আরও দেখুন কেন লাল — import-এর গোলমালে নয়, প্রত্যাশিত মান না মেলায়।
• Green — পাস করানোর ন্যূনতম কোড: এখন একমাত্র লক্ষ্য সবুজ। Beck-এর ভাষায়, এই মুহূর্তে যত “পাপ” দরকার করে ফেলুন — constant ফেরত দেওয়া, কোড কপি করা। সুন্দর কোডের চিন্তা পরের ধাপের। নতুন কোনো আচরণ এই ধাপে যোগ হয় না, যা test চায়নি।
• Refactor — test সবুজ রেখে গোছানো: green ধাপের পাপগুলো এখন শোধ করুন: test আর কোডের মধ্যে duplication (যেমন test-এর ১৩ আর কোডের ১৩), খারাপ নাম, লম্বা function. প্রতিটি ছোট বদলের পর test চালান। এটি পর্ব ৪২-এর refactoring — আচরণ একই, “দুই টুপি”-র refactoring-টুপি।

Test list আর baby steps

চক্র শুরুর আগে Beck একটি কাগজে লেখেন: এই কাজে কী কী test লাগবে বলে এখন মনে হচ্ছে। একে বলে test list. তালিকাটি সম্পূর্ণ হওয়ার দরকার নেই; কাজ চলতে চলতে নতুন ভাবনা (“শূন্য দূরত্ব হলে কী হবে?”) এলে তালিকায় যোগ করুন, কিন্তু সেই মুহূর্তে কোডে নয় — চলতি চক্র আগে শেষ। প্রতিটি সবুজের পর একটি item কেটে দিন। Beck ২০২৩ সালের “Canon TDD” লেখায় এই তালিকাকেই প্রথম ধাপ বলেছেন বলে আমাদের জানা।

নিচের stepper-এ একটি পুরো চক্র ধীরে ধীরে দেখুন। প্রেক্ষাপট একটি কাল্পনিক শহরের বাস ভাড়ার হিসাব, যার পূর্ণ kata অংশ ৪-এ। প্রথম চক্রে fare(1)-এর জন্য ১০ টাকা ফেরত দিতে fare শুধু return 10 লিখেছে। এবার পরের item.

✔ 1 km   → 10 টাকা (ন্যূনতম)
▶ 4 km   → 13 টাকা
☐ 3 km   → 10 টাকা (সীমা)
☐ 3.2 km → 13 টাকা (শুরু করা কিমি = পুরো কিমি)
☐ ছাত্র, 10 km → 16 টাকা
☐ 0 km   → ValueError

# fare.py — আগের চক্রের পরে
def fare(km):
    return 10

def test_four_km_adds_one_extra_km(self):
    self.assertEqual(fare(4), 13)

$ python -m unittest
F.
FAIL: test_four_km_adds_one_extra_km (…)
…
AssertionError: 10 != 13
Ran 2 tests in 0.001s
FAILED (failures=1)

def fare(km):
    if km <= 3:
        return 10
    return 10 + (km - 3) * 3

$ python -m unittest
..
Ran 2 tests in 0.000s
OK
$ git commit -am "feat: add 3 taka per km after 3 km (triangulated)"

BASE_FARE, BASE_KM, PER_KM = 10, 3, 3

def fare(km):
    return BASE_FARE + max(0, km - BASE_KM) * PER_KM

$ python -m unittest
..
OK

$ git commit -am "refactor: name fare constants, drop the if"
$ git log --oneline -3
e254efc refactor: name fare constants, drop the if
36c8721 feat: add 3 taka per km after 3 km (triangulated)
8050ffd feat: charge minimum fare of 10 taka (fake it)

✔ 4 km → 13 টাকা   (তালিকা থেকে কাটা)

৩ · সবুজে পৌঁছানোর তিন কৌশল — fake it, triangulation, obvious implementation

Red থেকে green-এ যাওয়ার জন্য Beck তিনটি “green bar pattern” দেন। কোনটি নেবেন, তা নির্ভর করে সমাধানটি আপনি কতটা নিশ্চিতভাবে জানেন তার ওপর।

নিচের Python উদাহরণে একটি কাল্পনিক মোবাইল wallet-এর নিয়ম: প্রতি পূর্ণ ১০০ টাকা top-up-এ ১টি loyalty point. প্রথম test (৫০০ টাকা → ৫ point) একটি fake দিয়েই পাস করে। দ্বিতীয় test (১২৫০ → ১২) fake-কে ধরে ফেলে, আর তখন সাধারণ নিয়ম লিখতে হয়। একই দুটি test দুই সংস্করণে চালানো হয়েছে।

import unittest

# Fictional wallet rule: 1 loyalty point for every full 100 taka of a top-up.
def points_fake(amount):           # "fake it": a constant that passes test 1
    return 5

def points_general(amount):        # triangulated: two examples force the rule
    return amount // 100

def make_tests(points):
    class PointsTest(unittest.TestCase):
        def test_1_500_taka_gives_5(self):
            self.assertEqual(points(500), 5)
        def test_2_1250_taka_gives_12(self):
            self.assertEqual(points(1250), 12)
    return PointsTest

def run(label, points, upto):
    loader = unittest.defaultTestLoader
    tests = loader.loadTestsFromTestCase(make_tests(points))
    chosen = unittest.TestSuite(list(tests)[:upto])
    result = unittest.TestResult()
    chosen.run(result)
    print(f"{label}: ran {result.testsRun}, failed {len(result.failures)}")
    for test, tb in result.failures:
        print("   ", test.id().split(".")[-1], "->", tb.strip().splitlines()[-1])

run("fake, test 1 only   ", points_fake, 1)
run("fake, tests 1 and 2 ", points_fake, 2)
run("general, tests 1, 2 ", points_general, 2)
print("extra check: 99 ->", points_general(99), "| 100 ->", points_general(100))

fake, test 1 only   : ran 1, failed 0
fake, tests 1 and 2 : ran 2, failed 1
    test_2_1250_taka_gives_12 -> AssertionError: 5 != 12
general, tests 1, 2 : ran 2, failed 0
extra check: 99 -> 0 | 100 -> 1

৪ · একটি পূর্ণ TDD kata — কাল্পনিক শহরের বাস ভাড়া, চক্রে চক্রে

Code kata হলো বারবার করার মতো ছোট অনুশীলন — কারাতের kata যেমন একই নড়াচড়া বারবার অনুশীলন করা। নামটি Dave Thomas জনপ্রিয় করেন বলে সাধারণত বলা হয়; প্রচলিত kata-র মধ্যে আছে Roy Osherove-র String Calculator আর Robert C. Martin-এর Bowling Game. আমাদের kata-র নিয়মগুলো একটি সম্পূর্ণ কাল্পনিক শহরের বাসের:

• প্রথম ৩ কিমি পর্যন্ত ন্যূনতম ভাড়া ১০ টাকা।
• তারপর প্রতি কিমি ৩ টাকা; শুরু করা কিমি পুরো কিমি ধরা হয় (৩.২ কিমি মানে বাড়তি ১ কিমি)।
• ছাত্রছাত্রী অর্ধেক ভাড়া দেন; ভগ্নাংশ হলে ওপরের পূর্ণ টাকায় (৩১ টাকার অর্ধেক ১৫.৫ → ১৬)।
• দূরত্ব ০ বা ঋণাত্মক হলে error.

শুরুর test list ছয়টি item-এর, সহজ থেকে কঠিন ক্রমে সাজানো। নিচের stepper প্রতিটি চক্র দেখায় — নতুন test, লাল অবস্থায় runner-এর আসল বার্তা, সবুজে যাওয়ার কৌশল, আর commit. বার্তাগুলো প্রতিটি অবস্থার কোড Python ৩.১৪-এ চালিয়ে সংগ্রহ করা।

এবার kata-র শেষ অবস্থা — production কোড আর তার পুরো test suite. চালিয়ে দেখুন সব সবুজ কি না।

import math, unittest

BASE_FARE, BASE_KM, PER_KM = 10, 3, 3       # fictional city-bus fare rules

def fare(km, student=False):
    if km <= 0:
        raise ValueError("distance must be positive")
    extra_km = math.ceil(max(0, km - BASE_KM))   # a started km counts as a full km
    full = BASE_FARE + extra_km * PER_KM
    return math.ceil(full / 2) if student else full

class FareTest(unittest.TestCase):
    def test_one_km_costs_minimum(self):
        self.assertEqual(fare(1), 10)
    def test_four_km_adds_one_extra_km(self):
        self.assertEqual(fare(4), 13)
    def test_three_km_is_still_minimum(self):
        self.assertEqual(fare(3), 10)
    def test_partial_km_counts_as_full_km(self):
        self.assertEqual(fare(3.2), 13)
    def test_student_pays_half_rounded_up(self):
        self.assertEqual(fare(10, student=True), 16)
    def test_zero_km_is_rejected(self):
        with self.assertRaises(ValueError):
            fare(0)

suite = unittest.defaultTestLoader.loadTestsFromTestCase(FareTest)
names = [t.id().split(".")[-1] for t in suite]       # loader sorts names A-Z
result = unittest.TestResult()
suite.run(result)
bad = {t.id().split(".")[-1] for t, _ in result.failures + result.errors}
for n in names:
    print(("FAIL  " if n in bad else "ok    ") + n)
print(f"{result.testsRun} tests, {len(bad)} failed")

ok    test_four_km_adds_one_extra_km
ok    test_one_km_costs_minimum
ok    test_partial_km_counts_as_full_km
ok    test_student_pays_half_rounded_up
ok    test_three_km_is_still_minimum
ok    test_zero_km_is_rejected
6 tests, 0 failed

C1 red         0 ok, ERROR NameError: name 'fare' is not defined
C1 green       1 ok
C2 red         1 ok, FAIL AssertionError: 10 != 13
C2 green       2 ok
C2 refactor    2 ok
C3 (new test)  3 ok
C4 red         3 ok, FAIL AssertionError: 10.600000000000001 != 13
C4 green       4 ok
C5 red         4 ok, ERROR TypeError: fare() got an unexpected keyword argument 'student'
C5 green       5 ok
C6 red         5 ok, FAIL AssertionError: ValueError not raised
C6 green       6 ok

Git-এ kata: প্রতিটি সবুজে একটি commit

নিচের transcript একটি আসল scratch repository থেকে (Git ২.৫৩-এ, লেখক Rahim, তারিখ নির্দিষ্ট করে দেওয়া, তাই hash পুনরুৎপাদনযোগ্য)। প্রতিটি commit-এর আগে পুরো suite চালিয়ে সবুজ নিশ্চিত করা হয়েছিল।

$ git log --oneline --reverse
8050ffd feat: charge minimum fare of 10 taka (fake it)
36c8721 feat: add 3 taka per km after 3 km (triangulated)
e254efc refactor: name fare constants, drop the if
f39c6ad test: pin 3 km boundary at minimum fare
6e3091f feat: count a started km as a full km
c489225 feat: half fare for students, rounded up
6afd7c5 feat: reject zero or negative distance

$ git log --format="%h %ad %s" --date=format:%H:%M -3
6afd7c5 10:24 feat: reject zero or negative distance
c489225 10:20 feat: half fare for students, rounded up
6e3091f 10:16 feat: count a started km as a full km

$ git show --stat --format="%h %s" e254efc
e254efc refactor: name fare constants, drop the if

 fare.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

$ git show --stat --format="%h %s" f39c6ad
f39c6ad test: pin 3 km boundary at minimum fare

 test_fare.py | 2 ++
 1 file changed, 2 insertions(+)

৫ · TDD নকশায় চাপ দেয় — testable কোড, outside-in আর inside-out

TDD-তে কোডের প্রথম ব্যবহারকারী আপনি নিজেই — test-এর ভেতর থেকে। যে কোড test থেকে ডাকা কঠিন, TDD-তে সেই কোড লেখাই কঠিন। এই অস্বস্তিকেই বলা হয় TDD-র নকশার চাপ (design pressure). Steve Freeman আর Nat Pryce এর নাম দিয়েছেন “listening to the tests” — test লিখতে কষ্ট হলে সেটি নকশার একটি সংকেত, test-এর দোষ নয়।

একটি উদাহরণ নিন। কাল্পনিক বাস কোম্পানি ঠিক করল, ঈদের আগের তিন দিন ভাড়া ২০% বেশি, আর প্রতিটি টিকিটের পর যাত্রীকে SMS যাবে। TDD ছাড়া প্রথম খসড়া প্রায়ই এমন হয়:

import datetime, sms_gateway            # a real SMS service

def sell_ticket(km, phone):
    price = fare(km)
    if is_eid_week(datetime.date.today()):   # hidden dependency: the clock
        price = round(price * 1.2)
    sms_gateway.send(phone, f"Fare {price} taka")   # hidden side effect
    return price

এর test লিখতে গেলেই প্রশ্ন: ঈদের হিসাব যাচাই করতে কি ঈদ পর্যন্ত অপেক্ষা? প্রতিটি test কি সত্যিকারের SMS পাঠাবে? TDD-তে এই প্রশ্ন কোডের আগেই ওঠে, আর স্বাভাবিক উত্তর হয় dependency বাইরে থেকে দেওয়া:

def sell_ticket(km, phone, today, notifier):
    price = fare(km)
    if is_eid_week(today):                   # the date is an input now
        price = round(price * 1.2)
    notifier.send(phone, f"Fare {price} taka")  # any object with send()
    return price

# in a test:  sell_ticket(1, "01700000000", date(2026, 3, 18), FakeNotifier())

এখন তারিখ একটি সাধারণ input, আর SMS-এর জায়গায় test একটি নকল notifier দিতে পারে — পর্ব ৩৭-এর dependency injection, আর গভীরে পর্ব ২৮-এর dependency inversion principle. এই ধরনের নকশা testability বাড়ায়, আর সেই সাথে coupling কমায়: ব্যবসার নিয়ম আর SMS-এর প্রযুক্তি আলাদা হয়ে যায়, যা পর্ব ৪০-এর hexagonal architecture-এর port আর adapter-এর ছোট রূপ। নকল notifier কোন ধরনের test double — stub, fake, spy না mock — সেই পার্থক্য পর্ব ৪৯-এ।

দুই ধারা: inside-out (classic) আর outside-in (London)

কোথা থেকে শুরু করবেন — ভেতরের ছোট হিসাব থেকে, না বাইরের ব্যবহারকারীর দিক থেকে? এ নিয়ে দুটি প্রচলিত ধারা আছে। নামগুলো আনুষ্ঠানিক নয়; Martin Fowler ২০০৭ সালের “Mocks Aren't Stubs” লেখায় দুই দলকে “classicist” আর “mockist” বলেছেন, আর অনেকে জায়গার নামে “Detroit/Chicago school” আর “London school” বলেন।

বাস ভাড়ার kata ছিল inside-out: একটি বিশুদ্ধ হিসাব, কোনো collaborator নেই। টিকিট বিক্রির পুরো feature হলে outside-in শুরু হতো “টিকিট কিনলে ভাড়া দেখায় আর SMS যায়” — এই acceptance test থেকে, আর notifier-এর interface আবিষ্কার হতো mock দিয়ে। বাস্তবে বেশিরভাগ দল দুটি মেশায়।

৬ · ATDD আর BDD — বাইরের চক্র

TDD-র ছোট চক্র নিশ্চিত করে যে প্রতিটি টুকরো যা করার কথা তা করে। কিন্তু “কী করার কথা” — সেটি কে ঠিক করে? পর্ব ২২-এ দেখেছেন, user story-র acceptance criteria সেই উত্তর দেয়, আর Given-When-Then উদাহরণে লিখলে তা দ্ব্যর্থহীন হয়। Acceptance test-driven development (ATDD) এই উদাহরণগুলোকে কাজ শুরুর আগেই স্বয়ংক্রিয় acceptance test বানায়। সেগুলো শুরুতে ফেল করে; story শেষ ধরা হয় যখন সব পাস করে।

Freeman ও Pryce-এর বইয়ে বাইরের আর ভেতরের feedback চক্রের এই ছবি আছে; অনেকে একে double-loop TDD বলেন। ATDD-র শিকড় আরও পুরোনো: Ward Cunningham-এর FIT (২০০২-এর দিকে) টেবিলে লেখা উদাহরণকে acceptance test হিসেবে চালাত, আর Gojko Adzic-এর specification by example একই ভাবনার বড় রূপ।

BDD — শব্দ বদলালে ভাবনা বদলায়

Behaviour-driven development (BDD) এসেছে TDD শেখানোর একটি সমস্যা থেকে। Dan North ২০০৬ সালের “Introducing BDD” লেখায় বলেন, TDD শিখতে আসা মানুষ বারবার একই প্রশ্ন করতেন: কোথা থেকে শুরু করব, কী test করব, কী নয়, test-এর নাম কী দেব, ফেল করলে বুঝব কীভাবে? তাঁর উত্তর ছিল শব্দ বদলানো: “test”-এর বদলে “behaviour”, আর test-এর নাম একটি বাক্য — should charge minimum fare for short trips. প্রশ্ন তখন হয়ে যায় “system-এর পরের কোন আচরণটি সবচেয়ে জরুরি?” North এই ভাবনায় JBehave নামে একটি Java framework লেখেন, আর Chris Matts-এর সাথে Given-When-Then ছাঁচে পৌঁছান বলে উল্লেখ করেন।

BDD-র তিনটি মূল উপাদান:

• সবার এক ভাষা: Eric Evans-এর domain-driven design (২০০৩) থেকে নেওয়া ubiquitous language — ব্যবসার মানুষ যে শব্দ বলেন (“top-up”, “ব্যালান্স”, “loyalty point”), scenario আর কোডেও ঠিক সেই শব্দ।
• উদাহরণই specification: Given-When-Then scenario মানুষ পড়তে পারে আবার tool চালাতেও পারে — একটি executable specification. নিয়মিত চালানো হয় বলে এটি living documentation: কোড বদলালে দলিল নিজেই লাল হয়ে জানায়, পুরোনো হয়ে পড়ে থাকে না।
• আলাপ আগে, automation পরে: scenario লেখার আগে three amigos — ব্যবসার প্রতিনিধি (যেমন product owner), developer আর tester — একসাথে বসে নিয়ম আর উদাহরণ ঠিক করেন। নামটি জনপ্রিয় করার কৃতিত্ব সাধারণত George Dinwiddie-কে দেওয়া হয়। এমন আলোচনার একটি জনপ্রিয় কৌশল example mapping (Matt Wynne, ২০১৫-র দিকে): story হলুদ কার্ডে, নিয়ম নীলে, উদাহরণ সবুজে, অমীমাংসিত প্রশ্ন লালে।

ATDD আর BDD-র সীমানা ঝাপসা; অনেকে দুটিকে একই চর্চার দুই নাম বলেন — পরীক্ষায় এই মতভেদটুকুও উল্লেখ করুন।

৭ · Step definition — Gherkin-এর লেখা থেকে কোড পর্যন্ত

পর্ব ২২-এর কাল্পনিক রিচার্জ অ্যাপের Gherkin scenario মনে করুন: “Given my wallet balance is 500 taka, When I top up 100 taka…”। লেখাটি নিজে কিছু চালায় না। একটি BDD tool লেখাটিকে কোডের সাথে জোড়ে step definition দিয়ে: প্রতিটি ধাপের লেখার একটি ছাঁচ (regular expression, বা কিছু tool-এ {int} ধরনের সহজ expression) আর একটি function. মোটামুটি সব tool একই কাজ করে:

1. Feature file পড়ে প্রতিটি scenario-র ধাপগুলো আলাদা করে।
2. Given/When/Then/And/But keyword বাদ দিয়ে বাকি লেখা প্রতিটি step definition-এর ছাঁচের সাথে মেলায়।
3. ছাঁচের বন্ধনীতে ধরা অংশ (যেমন 500) argument হয়ে function-এ যায়।
4. প্রতিটি scenario একটি নতুন, খালি context বা “world” object পায়।
5. একটি ধাপ ফেল করলে সেই scenario-র বাকি ধাপ চালানো হয় না (skipped); কোনো ছাঁচই না মিললে ধাপটি “undefined” বলে রিপোর্ট হয়।

প্রচলিত tool-এর মধ্যে আছে Cucumber (Ruby-তে শুরু, এখন JavaScript, Java-সহ অনেক ভাষায়), Python-এ behave আর pytest-bdd. ছাঁচের ব্যাকরণ আর রিপোর্টের ধরন tool আর সংস্করণভেদে আলাদা — লেখার সময়ের অবস্থা জানতে প্রতিটির documentation দেখুন। নিচের stepper একটি ধাপের পুরো যাত্রা দেখায়।

Scenario: Not enough balance
  Given my wallet balance is 50 taka
  When I top up 100 taka
  Then my balance should be 50 taka
  And I should see "Not enough money"

লেখা:  "my balance should be 50 taka"

/^my wallet balance is (\d+) taka$/   ✗
/^I top up (\d+) taka$/              ✗
/^I should see "(.*)"$/              ✗
/^my balance should be (\d+) taka$/   ✓  ধরা অংশ: "50"

Given → w.balance = 50
When  → w.msg = topUp(w, 100)

function topUp(wallet, amount) {
  wallet.balance -= amount;      // আগে কাটে …
  return wallet.balance < 0 ? "Not enough money" : …
}
w = { balance: -50, msg: "Not enough money" }

(w, b) => {
  if (w.balance !== +b)            // -50 !== 50
    throw `balance is ${w.balance}`;
}

Scenario: Not enough balance
  PASS Given my wallet balance is 50 taka
  PASS When I top up 100 taka
  FAIL Then my balance should be 50 taka  <- balance is -50
  SKIP And I should see "Not enough money"

এবার পুরো ব্যাপারটি চালিয়ে দেখুন — দুটি scenario, চারটি step definition, আর একটি কাল্পনিক wallet-এর topUp, যাতে ইচ্ছা করে একটি bug রাখা। এটি আসল BDD tool নয়: Background, Scenario Outline, টেবিল বা tag সামলায় না।

// A toy BDD runner: Gherkin lines -> regex step definitions -> code (fictional wallet)
const feature = `Scenario: Successful top-up
  Given my wallet balance is 500 taka
  When I top up 100 taka
  Then I should see "Top-up successful"
  And my balance should be 400 taka
Scenario: Not enough balance
  Given my wallet balance is 50 taka
  When I top up 100 taka
  Then my balance should be 50 taka
  And I should see "Not enough money"`;

function topUp(wallet, amount) {             // system under test (it has a bug)
  wallet.balance -= amount;                  // deducts BEFORE checking the balance
  return wallet.balance < 0 ? "Not enough money" : "Top-up successful";
}
const steps = [                              // step definitions: regex -> code
  [/^my wallet balance is (\d+) taka$/, (w, b) => { w.balance = Number(b); }],
  [/^I top up (\d+) taka$/, (w, a) => { w.msg = topUp(w, Number(a)); }],
  [/^I should see "(.*)"$/, (w, m) => { if (w.msg !== m) throw `saw "${w.msg}"`; }],
  [/^my balance should be (\d+) taka$/, (w, b) => { if (w.balance !== +b) throw `balance is ${w.balance}`; }],
];
let world, failed, pass = 0, fail = 0, skip = 0;
for (const line of feature.split("\n").map(l => l.trim())) {
  if (line.startsWith("Scenario:")) { world = {}; failed = false; console.log(line); continue; }
  const text = line.replace(/^(Given|When|Then|And|But) /, "");
  if (failed) { skip++; console.log("  SKIP " + line); continue; }
  const def = steps.find(([re]) => re.test(text));
  try {
    if (!def) throw "no matching step definition";
    def[1](world, ...text.match(def[0]).slice(1));
    pass++; console.log("  PASS " + line);
  } catch (e) { failed = true; fail++; console.log("  FAIL " + line + "  <- " + e); }
}
console.log(`steps: ${pass} passed, ${fail} failed, ${skip} skipped`);

Scenario: Successful top-up
  PASS Given my wallet balance is 500 taka
  PASS When I top up 100 taka
  PASS Then I should see "Top-up successful"
  PASS And my balance should be 400 taka
Scenario: Not enough balance
  PASS Given my wallet balance is 50 taka
  PASS When I top up 100 taka
  FAIL Then my balance should be 50 taka  <- balance is -50
  SKIP And I should see "Not enough money"
steps: 6 passed, 1 failed, 1 skipped

বাস্তব tool-এ একই step definition দেখতে কেমন? নিচে behave-ধাঁচের Python (এখানে চালানো হয়নি; behave আলাদা package). ছাঁচগুলো regular expression নয়, {balance:d} ধরনের সহজ format — যা সংখ্যায় রূপান্তরও করে দেয়। ভাগ করা অবস্থা থাকে context object-এ।

# features/steps/topup_steps.py  (illustration, needs: pip install behave)
from behave import given, when, then
from wallet import Wallet, top_up

@given("my wallet balance is {balance:d} taka")
def step_balance(context, balance):
    context.wallet = Wallet(balance)

@when("I top up {amount:d} taka")
def step_top_up(context, amount):
    context.message = top_up(context.wallet, amount)

@then('I should see "{message}"')
def step_message(context, message):
    assert context.message == message

@then("my balance should be {balance:d} taka")
def step_check_balance(context, balance):
    assert context.wallet.balance == balance

৮ · প্রমাণ কী বলে, কখন TDD নয়, আর সাধারণ ভুল

গবেষণার প্রমাণ — মিশ্র

TDD নিয়ে সবচেয়ে বেশি উদ্ধৃত শিল্প-গবেষণাগুলোর একটি Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat আর Laurie Williams-এর ২০০৮ সালের লেখা (Empirical Software Engineering জার্নালে)। তাঁরা চারটি শিল্প-দলের — একটি IBM-এর, তিনটি Microsoft-এর — case study করেন। লেখকদের রিপোর্ট অনুযায়ী, TDD ব্যবহারকারী দলগুলোর release-এর আগের defect density তুলনীয় অন্য project-এর চেয়ে উল্লেখযোগ্যভাবে কম ছিল (প্রায় ৪০% থেকে ৯০% কম, আমাদের জানামতে), আর দলগুলোর ব্যবস্থাপকদের হিসাবে শুরুর development সময় লেগেছিল আনুমানিক ১৫–৩৫% বেশি। কিন্তু এটি case study, randomized পরীক্ষা নয়: দলগুলো নিজেরাই TDD বেছেছিল, আর তুলনার project হুবহু এক নয়।

নিয়ন্ত্রিত পরীক্ষা আর meta-analysis-এর ছবি অস্পষ্টতর। কয়েকটি meta-analysis (যেমন Rafique ও Mišić, ২০১৩) গুণগত মানে ছোট উন্নতি পেয়েছে, কিন্তু productivity-তে স্পষ্ট লাভ বা ক্ষতি নয়। Davide Fucci ও সহকর্মীদের একটি গবেষণা (IEEE TSE, ২০১৭) ইঙ্গিত দেয় যে লাভের বড় অংশ হয়তো আসে ছোট, নিয়মিত ধাপ থেকে — test আগে না পরে, সেই ক্রম থেকে ততটা নয়। সৎ সারাংশ: TDD নিয়ে কোনো সংখ্যাকে সর্বজনীন সত্য বলা যায় না; প্রসঙ্গ, দলের দক্ষতা আর কাজের ধরন ফল বদলায়।

কখন খাটে, কখন খাটে না

সাধারণ ভুল

ধাপ কত বড় হচ্ছে, তা অনুভবে না রেখে মাপা যায়। নিচের মডেল একটি অনুশীলন-সেশনের লগ (সম্পূর্ণ কাল্পনিক) পড়ে: প্রতিটি লাইনে সময় আর ঘটনা — red মানে নতুন test লেখা শুরু, green মানে সব test সবুজ, refactor মানে গোছানো শুরু, end সেশন শেষ। ধরে নেওয়া হয়েছে: একটি চক্র শুরু হয় red-এ আর শেষ হয় পরের red বা end-এ; প্রতিটি অবস্থা চলে পরের ঘটনা পর্যন্ত; ১০ মিনিটের বেশি চক্র “giant step”. সীমাটি একটি নিয়মমাফিক পছন্দ, কোনো মানদণ্ড নয়।

// TDD session log -> cycles and time per phase (fictional log of one practice session)
// Assumptions: a cycle starts at "red" and ends at the next "red" or at "end";
// a phase lasts until the next event; a cycle over 10 min is flagged as a giant step.
const log = `00:00 red|01:30 green|02:10 refactor|03:00 red|04:20 green|05:30 refactor|
07:00 red|07:40 green|08:30 red|10:00 green|10:50 refactor|12:00 red|25:30 green|
26:00 red|27:10 green|28:00 refactor|29:30 end`;
const ev = log.replace(/\s+/g, " ").split("|").map(s => s.trim().split(" "))
  .map(([t, p]) => ({ sec: +t.slice(0, 2) * 60 + +t.slice(3), p }));
const mmss = s => `${String(Math.floor(s / 60)).padStart(2, "0")}:${String(s % 60).padStart(2, "0")}`;
const cycles = [], total = { red: 0, green: 0, refactor: 0 };
for (let i = 0; i < ev.length - 1; i++) {
  const d = ev[i + 1].sec - ev[i].sec;
  if (ev[i].p === "red") cycles.push({ start: ev[i].sec, red: 0, green: 0, refactor: 0 });
  const c = cycles[cycles.length - 1];
  c[ev[i].p] += d; total[ev[i].p] += d;
}
cycles.forEach((c, k) => {
  const len = c.red + c.green + c.refactor;
  const notes = [len > 600 ? "GIANT STEP" : "", c.refactor === 0 ? "no refactor" : ""].filter(Boolean);
  console.log(`cycle ${k + 1} at ${mmss(c.start)}: red ${mmss(c.red)} green ${mmss(c.green)}` +
    ` refactor ${mmss(c.refactor)} = ${mmss(len)}` + (notes.length ? "  " + notes.join(", ") : ""));
});
const all = ev[ev.length - 1].sec;
for (const p of ["red", "green", "refactor"])
  console.log(`${p.padEnd(8)} ${mmss(total[p])} (${Math.round(100 * total[p] / all)}%)`);
console.log(`${cycles.length} cycles in ${mmss(all)}, mean ${mmss(Math.round(all / cycles.length))} per cycle`);

cycle 1 at 00:00: red 01:30 green 00:40 refactor 00:50 = 03:00
cycle 2 at 03:00: red 01:20 green 01:10 refactor 01:30 = 04:00
cycle 3 at 07:00: red 00:40 green 00:50 refactor 00:00 = 01:30  no refactor
cycle 4 at 08:30: red 01:30 green 00:50 refactor 01:10 = 03:30
cycle 5 at 12:00: red 13:30 green 00:30 refactor 00:00 = 14:00  GIANT STEP, no refactor
cycle 6 at 26:00: red 01:10 green 00:50 refactor 01:30 = 03:30
red      19:40 (67%)
green    04:50 (16%)
refactor 05:00 (17%)
6 cycles in 29:30, mean 04:55 per cycle

৯ · AI-এর যুগে TDD আর BDD

AI সহকারী কয়েক সেকেন্ডে test আর কোড দুটিই লিখে দেয়। এতে TDD-র মূল্য বাড়ে: AI-এর কোড যাচাইয়ের সবচেয়ে ভরসার উপায় আপনার লেখা, আগে লাল দেখা test. আর AI দিয়ে কোড থেকে test বানালে TDD-র উদ্দেশ্যই উল্টে যায়।

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

• প্রতিটি নতুন test আগে চালিয়ে লাল দেখেছি, আর লালের কারণ প্রত্যাশিত
• প্রত্যাশিত মানগুলো requirement থেকে নিজে হিসাব করেছি, কোড থেকে নয়
• কোড ইচ্ছা করে একটু ভেঙে (যেমন <= থেকে <) দেখেছি test ধরে কি না
• Test বাইরের আচরণ যাচাই করে; private method বা ভেতরের ডাকের ক্রম নয়
• Gherkin scenario ব্যবসার মানুষ পড়ে সায় দিয়েছেন; step definition পাতলা
• AI-এর দেওয়া Git command আগে throwaway clone-এ চালিয়েছি; prompt-এ কোনো secret দিইনি