টেস্টিং — pytest দিয়ে কোডের প্রতিশ্রুতি যাচাই

১ · টেস্ট কী, আর কেন লিখবেন

ধরুন আপনি একটি দোকানের বিলিং সফটওয়্যার লিখছেন। একটি ফাংশন আছে add_vat(price) — দামের সাথে ১৫% VAT যোগ করে। আপনি একবার চালিয়ে দেখলেন, add_vat(100) দিল 115. চমৎকার। তিন সপ্তাহ পরে ছাড়ের নিয়ম যোগ করতে গিয়ে আপনি একই ফাইলে কিছু লাইন বদলালেন। এখন add_vat(100) কত দেয়? আপনি জানেন না — যতক্ষণ না আবার চালিয়ে দেখছেন। আর বিলিং ফাংশন তো একটি নয়, চল্লিশটি।

এই সমস্যার উত্তর হলো একটি unit test: একটি ছোট প্রোগ্রাম, যা আপনার প্রোগ্রামের একটি প্রতিশ্রুতি যাচাই করে. “add_vat(100) দেয় 115” — এই কথাটি একবার কোডে লিখে রাখলে কম্পিউটার যতবার খুশি, এক সেকেন্ডের ভগ্নাংশে, আপনার হয়ে মিলিয়ে দেবে। এমন শত শত টেস্টের সংগ্রহকে বলে test suite.

টেস্ট তিনটি কাজ করে

• পুরোনো বাগ ফিরে আসা ধরে: একবার ঠিক করা বাগ পরে অন্য কোনো পরিবর্তনে আবার ফিরে আসাকে বলে regression. পর্ব ২১-এর মাঝপথের প্রজেক্টে নিয়মটি দেখেছেন: প্রতিটি ধরা পড়া বাগের জন্য একটি টেস্ট, চিরকালের জন্য। সেই টেস্ট পাহারাদার — বাগটি ফিরলেই লাল বাতি জ্বলে।
• নির্ভয়ে কোড বদলাতে দেয়: পর্ব ২১-এ refactoring মানে “বাইরের আচরণ একই রেখে ভেতরের গঠন গোছানো”. কিন্তু “আচরণ একই আছে” — এটা আপনি জানবেন কীভাবে? টেস্ট দিয়ে। ভালো test suite থাকলে চল্লিশটি ফাংশনের কোড গুছিয়ে pytest চালান — সব সবুজ হলে আপনি নিশ্চিন্ত। টেস্ট ছাড়া মানুষ পুরোনো কোড ছুঁতে ভয় পায়, আর কোড ধীরে ধীরে জট পাকায়।
• কোডের আচরণ লিখে রাখে: test_withdraw_more_than_balance_raises নামের একটি টেস্ট পড়েই নতুন সহকর্মী বোঝেন, ব্যালান্সের বেশি তুললে error আসার কথা। এটি এমন ডকুমেন্টেশন, যা কখনো পুরোনো হয় না — কারণ পুরোনো হলে টেস্টটিই ব্যর্থ হয়।

কত বড় অংশ টেস্ট করছেন?

এই পর্বের বেশিরভাগ জুড়ে আছে unit test — একটি ফাংশন বা class আলাদা করে, নেটওয়ার্ক বা ডেটাবেস ছাড়া, মিলিসেকেন্ডে। এর ওপরে আছে integration test — কয়েকটি অংশ একসাথে (আপনার কোড আর একটি আসল SQLite ফাইল, বা দুটি module), কিছুটা ধীর। আর সবার ওপরে end-to-end টেস্ট — পুরো অ্যাপ, যেন একজন ব্যবহারকারী বোতাম চাপছেন। সাধারণ পরামর্শ: অনেক দ্রুত unit test, তার চেয়ে কম integration test, আর অল্প কয়েকটি end-to-end — একে অনেকে “টেস্ট পিরামিড” বলেন।

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

প্রায় প্রতিটি ভালো unit test তিনটি অংশে ভাগ করা যায়। এই ছাঁচের নাম Arrange–Act–Assert (সংক্ষেপে AAA):

• Arrange — সাজানো: টেস্টের জন্য দরকারি ডেটা আর object তৈরি করা। যেমন দুটি wallet, একটিতে ৫০০ টাকা।
• Act — একটি কাজ: যে আচরণ যাচাই করছেন, সেটি একবার ঘটানো। যেমন ২০০ টাকা পাঠানো।
• Assert — মেলানো: ফল যা হওয়ার কথা, তা-ই হয়েছে কি না পরীক্ষা করা। যেমন একজনের ৩০০, অন্যজনের ২০০।

পর্ব ১৩-এ দেখেছেন, assert একটি statement: শর্ত সত্য হলে কিছুই ঘটে না, মিথ্যা হলে AssertionError আসে। টেস্টের Assert অংশ ঠিক এটিই। নিচের স্টেপারে একটি টেস্ট ফাংশনের ভেতর দিয়ে ধাপে ধাপে চলুন — শেষ ধাপে দেখবেন, কোডে বাগ থাকলে কী ঘটে:

1def test_transfer_moves_money():2    bal = {"rahim": 500, "karim": 0}       # Arrange3    transfer(bal, "rahim", "karim", 200)   # Act4    assert bal == {"rahim": 300, "karim": 200}  # Assert

pytest ছাড়াও এই ধারণা চলে। নিচের runnable প্রোগ্রামটি একটি ছোট নিজের হাতে বানানো test runner: কয়েকটি টেস্ট ফাংশন একে একে ডাকে, AssertionError ধরে “FAIL” ছাপে, আর শেষে গণনা দেখায়। pytest ভেতরে মূলত এই কাজটিই করে, অনেক বেশি সুবিধাসহ। grade() ফাংশনটি SSC-ধাঁচের লেটার গ্রেড দেয় (৮০–১০০ হলো A+, ৭০–৭৯ হলো A …, ৩৩-এর নিচে F), আর এর ভেতরে একটি বাগ লুকানো আছে। চালানোর আগে অনুমান করুন, কোন টেস্টটি ধরবে:

def grade(marks):
    if not 0 <= marks <= 100:
        raise ValueError(f"marks must be 0-100, got {marks}")
    for cut, letter in [(80, "A+"), (70, "A"), (60, "A-"), (50, "B"), (40, "C"), (33, "D")]:
        if marks > cut:                         # বাগটি এখানেই লুকানো
            return letter
    return "F"
def test_boundary_80():
    assert grade(80) == "A+", f"grade(80) = {grade(80)!r}"
def test_just_below_80():
    assert grade(79) == "A"
def test_zero_is_fail():
    assert grade(0) == "F"

failed = 0
for test in (test_boundary_80, test_just_below_80, test_zero_is_fail):
    try:
        test()                                  # Arrange-Act-Assert ভেতরে
    except AssertionError as err:
        failed += 1
        print(f"FAIL {test.__name__}: {err}")
print(f"3 tests, {failed} failed")

ভালো টেস্টের কয়েকটি গুণ

• দ্রুত: হাজারটি unit test কয়েক সেকেন্ডে শেষ হওয়া উচিত, নইলে কেউ চালাবে না।
• স্বাধীন: যেকোনো ক্রমে, একা বা সবার সাথে চালালে একই ফল।
• পুনরাবৃত্তিযোগ্য: আজকের তারিখ, এলোমেলো সংখ্যা বা নেটওয়ার্কের ওপর নির্ভর করলে কাল ব্যর্থ হতে পারে — এগুলো নিয়ন্ত্রণে আনতে হয় (অংশ ৬ আর ৭)।
• আচরণ যাচাই করে, ভেতরের খুঁটিনাটি নয়: “ফল কী হলো” দেখুন, “কোন private ফাংশন কতবার ডাকা হলো” নয় — নইলে প্রতিটি refactoring-এ টেস্ট ভাঙবে, অথচ আচরণ ঠিকই আছে।
• নাম একটি বাক্য: test_1 নয়, test_zero_marks_gives_f. ব্যর্থ হলে নামটিই প্রথম খবর।

৩ · pytest-এর শুরু — ফাইল, কমান্ড আর আউটপুট পড়া

Python-এর সাথে unittest নামের একটি টেস্ট-কাঠামো আসে (অংশ ৮)। কিন্তু আজকের বেশিরভাগ Python প্রজেক্ট ব্যবহার করে pytest — একটি third-party package, যা কম লিখে বেশি কাজ করায়। পর্ব ২৩-এর মতো virtual environment চালু করে ইনস্টল করুন:

pip install pytest
pytest --version

pytest টেস্ট খোঁজে নামের নিয়মে

আপনি pytest-কে বলেন না কোন ফাংশন টেস্ট; সে নিজেই খুঁজে নেয়। একে বলে test discovery. Default নিয়ম তিনটি: ফাইলের নাম test_*.py (বা *_test.py), ফাংশনের নাম test_ দিয়ে শুরু, আর class থাকলে তার নাম Test দিয়ে শুরু। পর্ব ২২-এর প্রজেক্ট কাঠামো মনে করুন:

shop/
├── pricing.py          # আসল কোড: add_vat, apply_discount
└── tests/
    ├── test_pricing.py # এখানে test_ ফাংশন
    └── test_wallet.py

from pricing import add_vat

def test_add_vat_on_round_price():
    assert add_vat(100) == 115

def test_add_vat_on_zero():
    assert add_vat(0) == 0

প্রজেক্টের মূল ফোল্ডার থেকে শুধু pytest চালালেই সব test_*.py ফাইল খুঁজে, প্রতিটি test_ ফাংশন ডেকে ফল জানায়। কয়েকটি কাজের option:

pytest                      # সব টেস্ট
pytest -v                   # প্রতিটি টেস্টের নাম আর PASSED/FAILED আলাদা লাইনে
pytest -x                   # প্রথম ব্যর্থতাতেই থামো
pytest -k vat               # যে টেস্টের নামে "vat" আছে, শুধু সেগুলো
pytest tests/test_wallet.py # শুধু একটি ফাইল
pytest --lf                 # গতবার যেগুলো ব্যর্থ হয়েছিল, শুধু সেগুলো

আউটপুট পড়া — ডট, F আর E

ধরা যাক test_grade.py-তে ছয়টি টেস্ট, আর আগের সেই > বনাম >= বাগটি আছে। pytest চালালে আপনি মোটামুটি এমন কিছু দেখবেন (version আর সময় আপনার কম্পিউটারে আলাদা হবে):

$ pytest
============================= test session starts ==============================
platform linux -- Python 3.13.1, pytest-8.3.4, pluggy-1.5.0
rootdir: /home/rahim/shop
collected 6 items

tests/test_grade.py .F....                                               [100%]

=================================== FAILURES ===================================
_______________________________ test_boundary_80 _______________________________

    def test_boundary_80():
>       assert grade(80) == "A+"
E       AssertionError: assert 'A' == 'A+'
E
E         - A+
E         + A

tests/test_grade.py:9: AssertionError
=========================== short test summary info ============================
FAILED tests/test_grade.py::test_boundary_80 - AssertionError: assert 'A' == 'A+'
========================= 1 failed, 5 passed in 0.03s ==========================

লাইন ধরে পড়ুন:

• collected 6 items: pytest ছয়টি টেস্ট খুঁজে পেয়েছে। সংখ্যাটি আপনার ধারণার চেয়ে কম হলে কোনো ফাইল বা ফাংশনের নামে test_ ভুল লেখা।
• .F....: প্রতিটি অক্ষর একটি টেস্ট, যে ক্রমে চলেছে। . মানে পাস, F মানে assert ব্যর্থ (failure), E মানে টেস্টের প্রস্তুতিতে বা পরিষ্কারে (fixture-এর setup বা teardown) exception (error) — যেমন fixture-এ KeyError. টেস্ট ফাংশনের ভেতরে অপ্রত্যাশিত exception হলে সেটিও F হিসেবেই দেখায়। আরও দেখবেন s (skip করা) আর x (জেনেশুনে ব্যর্থ হিসেবে চিহ্নিত)।
• > চিহ্নের লাইন: ঠিক কোন লাইনে ব্যর্থ হয়েছে। নিচের E লাইনগুলো বলে কেন: বাঁ পাশে আসল ফল 'A', ডান পাশে প্রত্যাশা 'A+'. - আর + দেওয়া অংশটি একটি diff — লম্বা string, list বা dict-এ ঠিক কোথায় অমিল, তা দেখায়।
• শেষ লাইন: সারসংক্ষেপ। কোনো টেস্ট ব্যর্থ হলে pytest-এর exit code হয় 1, সব পাস হলে 0 — অংশ ৯-এর CI এই সংখ্যাটি দেখেই সিদ্ধান্ত নেয়।

সাধারণ assert কেন যথেষ্ট — assertion rewriting

সাধারণ Python-এ assert grade(80) == "A+" ব্যর্থ হলে শুধু বলে AssertionError — কোন মান এসেছিল, বলে না। তাহলে pytest দুই পাশের মান জানল কীভাবে? উত্তর: assertion rewriting. টেস্ট ফাইল import করার সময় pytest তার কোড (পর্ব ০৫-এর AST স্তরে) একটু বদলে নেয়: প্রতিটি assert-এর দুই পাশের মান আগে আলাদা ভ্যারিয়েবলে রাখে, যাতে ব্যর্থ হলে সেগুলো ছাপা যায়। ফলে আপনাকে assertEqual, assertIn, assertGreater-এর মতো ডজনখানেক method মনে রাখতে হয় না — ==, in, >, not লিখলেই চলে। ভাবনার প্রশ্ন ২-এ দেখবেন, এই সিদ্ধান্তই pytest-কে জনপ্রিয় করেছে।

প্রত্যাশিত exception — pytest.raises

অনেক প্রতিশ্রুতি হলো “ভুল ইনপুটে error দেবে”: ঋণাত্মক দামে ValueError, ব্যালান্সের বেশি পাঠালে ব্যর্থতা। এটি টেস্ট করতে pytest.raises একটি context manager (পর্ব ৩৬) হিসেবে কাজ করে: with-এর ভেতরে নির্দিষ্ট exception এলে টেস্ট পাস; না এলে টেস্ট ব্যর্থ।

import pytest
from pricing import add_vat

def test_negative_price_is_rejected():
    with pytest.raises(ValueError, match="negative"):
        add_vat(-5)

def test_vat_on_paisa_price():
    assert add_vat(19.99) == pytest.approx(22.9885)
    assert 0.1 + 0.2 == pytest.approx(0.3)

match= একটি regular expression (পর্ব ২৮), যা error-বার্তার সাথে মেলানো হয় — এতে নিশ্চিত হন যে ঠিক কারণেই error এসেছে, অন্য কোনো ValueError নয়।

Float তুলনা — pytest.approx

পর্ব ০৭-এ দেখেছেন, floating point-এ 0.1 + 0.2 ঠিক 0.3 নয়, বরং 0.30000000000000004. আরও চমকপ্রদ: 100 * 1.15-এর ফল 114.99999999999999! অর্থাৎ add_vat ভেতরে price * 1.15 করলে এই অংশের শুরুর test_add_vat_on_round_price (== 115) আসলে ব্যর্থ হবে — অথচ হিসাবটি কার্যত ঠিক। pytest.approx বলে “প্রায় সমান হলেই চলবে” — default-এ আপেক্ষিক পার্থক্য দশ লাখ ভাগের এক ভাগের (1e-6) মধ্যে হলে সমান ধরে। দরকার হলে approx(x, abs=0.01) দিয়ে নিজের সীমা দিন। (টাকার হিসাবে আসল সমাধান অবশ্য পর্ব ০৭-এর Decimal; তখন সরাসরি == চলে।)

৪ · parametrize — এক টেস্টে অনেক কেস, নজর সীমায়

গ্রেড ফাংশনের জন্য কতগুলো টেস্ট দরকার? প্রতিটি গ্রেডের সীমার দুই পাশ (৮০/৭৯, ৭০/৬৯ …), দুই প্রান্ত (০ আর ১০০), আর দুটি অবৈধ মান (−১ আর ১০১)। এক-একটি আলাদা ফাংশন লিখলে বিশটি প্রায় একই রকম ফাংশন — কপি-পেস্টের কারখানা। সমাধান হলো parametrize: একটি টেস্ট ফাংশন লিখুন, আর তার ওপরে কেসগুলোর একটি তালিকা দিন। pytest প্রতিটি কেসের জন্য আলাদা টেস্ট বানিয়ে চালায়। এটি একটি decorator factory — পর্ব ৩৫-এ যার ছাঁচ দেখেছেন।

ঠিক সীমার মান আর তার ঠিক নিচের মান — boundary value — বেছে নেওয়ার কারণটি আগের runnable প্রোগ্রামেই দেখেছেন: > বনাম >=-এর মতো ভুল শুধু সীমাতেই ধরা পড়ে। নিচের স্টেপারে grade()-এর একটি if/elif সংস্করণ, যার প্রথম শর্তে লেখা marks > 80 (বাকিগুলোয় ঠিকঠাক >=)। একটি টেস্ট কীভাবে ছয়টি হয়ে যায় দেখুন:

1@pytest.mark.parametrize("marks, want", [2    (100, "A+"), (80, "A+"), (79, "A"),3    (33, "D"), (32, "F"), (0, "F"),4])5def test_grade(marks, want):6    assert grade(marks) == want

অবৈধ মানের জন্য আলাদা একটি parametrize, কারণ এখানে প্রত্যাশা একটি মান নয়, একটি exception:

@pytest.mark.parametrize("marks", [-1, 101])
def test_out_of_range_marks_raise(marks):
    with pytest.raises(ValueError):
        grade(marks)

বাস্তব উদাহরণ — বাংলাদেশি ফোন নম্বর

একটি ফাংশন parse_phone(raw) ব্যবহারকারীর লেখা নম্বর নিয়ে ১১ অঙ্কের একটি নির্দিষ্ট রূপ (01XXXXXXXXX) ফেরত দেয়, আর ভুল নম্বরে ValueError দেয়। মানুষ নম্বর লেখে নানা রূপে — +880 দিয়ে, 880 দিয়ে, মাঝে ফাঁকা রেখে। parametrize এখানে একটি স্পেসিফিকেশনের মতো পড়া যায়:

@pytest.mark.parametrize("raw, want", [
    ("01712345678",    "01712345678"),
    ("+8801712345678", "01712345678"),
    ("8801912345678",  "01912345678"),
    ("017 1234 5678",  "01712345678"),
])
def test_valid_numbers_are_normalized(raw, want):
    assert parse_phone(raw) == want

@pytest.mark.parametrize("raw", [
    "",              # খালি
    "0171234567",    # ১০ অঙ্ক — একটি কম
    "01212345678",   # 012 — কোনো অপারেটর নেই
    "017১২৩৪৫৬৭৮",   # বাংলা অঙ্ক মেশানো — সিদ্ধান্ত: নেব না
])
def test_invalid_numbers_raise(raw):
    with pytest.raises(ValueError):
        parse_phone(raw)

শেষ কেসটি খেয়াল করুন। পর্ব ২৮-এর regex-এ \d শুধু 0–9 নয়, যেকোনো Unicode অঙ্ক মেলায় — বাংলা ১২৩-ও! তাই r"01[3-9]\d{8}" প্যাটার্নটি "017১২৩৪৫৬৭৮"-কে বৈধ বলে দেবে, অথচ SMS গেটওয়ে সেটি বুঝবে না। এই টেস্টটি না থাকলে বাগটি ধরা পড়ত প্রথম বাংলা কি-বোর্ড ব্যবহারকারীর অভিযোগে। সমাধান [0-9] বা re.ASCII — অথবা সিদ্ধান্ত নিন যে বাংলা অঙ্ক ইংরেজিতে রূপান্তর করে নেবেন। যে সিদ্ধান্তই নিন, টেস্টে লিখে রাখুন; তখন সিদ্ধান্তটি আর কারও স্মৃতির ওপর নির্ভর করে না।

৫ · fixture — টেস্টের প্রস্তুতি আর পরিষ্কার

wallet-এর দশটি টেস্টের প্রতিটির শুরুতে যদি একই তিন লাইন থাকে — “একটি wallet বানাও, মালিক রহিম, ব্যালান্স ৫০০” — তাহলে সেটি একবার লিখে সবাইকে দেওয়া যায়। pytest-এ এর নাম fixture: @pytest.fixture দিয়ে চিহ্নিত একটি ফাংশন, যা টেস্টের জন্য দরকারি জিনিস তৈরি করে দেয়। টেস্ট ফাংশন সেটি চায় শুধু parameter-এর নাম লিখে:

import pytest
from wallet import Wallet

@pytest.fixture
def wallet():
    return Wallet(owner="রহিম", balance=500)

def test_withdraw_reduces_balance(wallet):     # নাম মিলিয়ে fixture আসে
    wallet.withdraw(200)
    assert wallet.balance == 300

def test_withdraw_too_much_changes_nothing(wallet):
    with pytest.raises(ValueError, match="insufficient"):
        wallet.withdraw(900)
    assert wallet.balance == 500               # ব্যর্থ লেনদেনে টাকা অক্ষত

এটি আসলে dependency injection — পর্ব ৩৩-এ যা দেখেছেন: টেস্ট নিজে wallet বানায় না, বাইরে থেকে হাতে পায়। আর গুরুত্বপূর্ণ কথা: প্রতিটি টেস্ট নতুন একটি wallet পায়. প্রথম টেস্ট ২০০ তুলে নিলেও দ্বিতীয় টেস্ট আবার ৫০০ দিয়ে শুরু করে। টেস্টগুলো একে অপরের ওপর নির্ভর করে না।

yield fixture — প্রস্তুতির পরে পরিষ্কারও

কিছু জিনিস তৈরির পরে গুছিয়ে রাখতে হয়: খোলা ফাইল বন্ধ করা, অস্থায়ী ডেটাবেস মুছে ফেলা। fixture-এ return-এর বদলে yield লিখলে (পর্ব ৩৪-এর generator) yield-এর আগের অংশ প্রস্তুতি (setup), পরের অংশ পরিষ্কার (teardown). সঙ্গে আরেকটি তৈরি fixture: tmp_path — প্রতিটি টেস্টের জন্য একটি নতুন খালি অস্থায়ী ফোল্ডার, পর্ব ২৫-এর pathlib.Path হিসেবে। আসল ফাইলে হাত না দিয়ে ফাইল-I/O টেস্ট করার নিরাপদ উপায়।

def test_add_entry(ledger):   # pytest নামটি দেখে
    ledger.write("1,500\n")   # @pytest.fixture def ledger খোঁজে
    ...

@pytest.fixture
def ledger(tmp_path):               # tmp_path-ও একটি fixture
    path = tmp_path / "ledger.csv"
    f = path.open("w", encoding="utf-8")
    yield f                            # এখানে থামে, f দেয়
    f.close()

def test_add_entry(ledger):
    ledger.write("1,500\n")
    assert ...                   # পাস হোক বা ব্যর্থ —
                                 # fixture অপেক্ষায় আছে

    yield f
    f.close()                          # ফাইল বন্ধ
# tmp_path ফোল্ডার pytest নিজে সামলায়;
# পরের টেস্ট পায় নতুন, খালি ফোল্ডার

fixture-এর scope আর conftest.py

Default-এ fixture প্রতিটি টেস্টের জন্য নতুন করে চলে — এটাই সবচেয়ে নিরাপদ। কিন্তু কিছু প্রস্তুতি ব্যয়বহুল: একটি টেস্ট ডেটাবেস তৈরি করতে দুই সেকেন্ড লাগলে পাঁচশো টেস্টে প্রায় ১৭ মিনিট! তখন fixture scope বাড়ানো যায়: @pytest.fixture(scope="module") মানে একটি ফাইলের সব টেস্ট একই object ভাগ করবে, scope="session" মানে পুরো pytest-চলায় একবার। মূল্য হলো ঝুঁকি — একটি টেস্ট ভাগ করা object বদলে দিলে পরের টেস্ট অন্য অবস্থা দেখবে। তাই বড় scope শুধু এমন জিনিসে, যা টেস্টগুলো বদলায় না (বা প্রতিটি টেস্টের পরে আগের অবস্থায় ফিরিয়ে দেওয়া হয়)।

অনেক ফাইলে একই fixture লাগলে সেটি রাখুন conftest.py নামের ফাইলে। pytest এই ফাইল নিজে খুঁজে পড়ে, আর তার fixture-গুলো সেই ফোল্ডার আর নিচের সব টেস্ট ফাইলে import ছাড়াই পাওয়া যায়।

৬ · print, input আর পরিবেশ — capsys আর monkeypatch

Pure function (পর্ব ১৩) টেস্ট করা সবচেয়ে সহজ: ইনপুট দিন, ফল মেলান। কিন্তু বাস্তবের ফাংশন কখনো print করে, কখনো input() দিয়ে পড়ে, কখনো environment variable থেকে API key নেয়। এগুলোর জন্য pytest দুটি তৈরি fixture দেয়।

capsys — যা ছাপা হলো, তা ধরা

capsys টেস্ট চলার সময় stdout আর stderr-এ লেখা সব কিছু ধরে রাখে। capsys.readouterr() দুটি string ফেরত দেয় — এ পর্যন্ত যা ছাপা হয়েছে:

def print_receipt(name, amount):
    print(f"{name}: {amount} টাকা")

def test_receipt_line(capsys):
    print_receipt("রহিম", 200)
    out, err = capsys.readouterr()
    assert out == "রহিম: 200 টাকা\n"      # print শেষে \n যোগ করে
    assert err == ""

monkeypatch — input আর পরিবেশ সাময়িক বদলানো

monkeypatch টেস্ট চলার সময় কোনো ফাংশন, attribute বা environment variable সাময়িকভাবে বদলে দেয়, আর টেস্ট শেষে নিজেই আগের অবস্থায় ফিরিয়ে আনে। টেস্টে তো কেউ কি-বোর্ডে টাইপ করবে না, তাই input-কে একটি ফাংশন দিয়ে বদলে দিন, যা নির্দিষ্ট উত্তর দেয়:

import os
import pytest

def ask_amount():
    return int(input("কত টাকা? "))

def load_api_key():
    return os.environ["SMS_API_KEY"]

def test_ask_amount(monkeypatch):
    monkeypatch.setattr("builtins.input", lambda prompt: "250")
    assert ask_amount() == 250

def test_api_key_comes_from_environment(monkeypatch):
    monkeypatch.setenv("SMS_API_KEY", "test-key")
    assert load_api_key() == "test-key"

def test_missing_api_key_raises(monkeypatch):
    monkeypatch.delenv("SMS_API_KEY", raising=False)
    with pytest.raises(KeyError):
        load_api_key()

লক্ষ করুন, টেস্টে কখনো আসল API key নেই — একটি নকল "test-key". আর তৃতীয় টেস্টটি একটি edge case পাহারা দেয়: key না থাকলে কী হয়? এ ধরনের টেস্ট প্রায়ই বাদ পড়ে, অথচ নতুন সার্ভারে deploy করার দিন ঠিক এটিই ঘটে।

৭ · test double — fake বনাম mock

wallet থেকে টাকা পাঠালে গ্রাহককে SMS যায়। টেস্ট চালালেই কি সত্যিকারের SMS যাবে? না — তাতে টাকা খরচ, নেটওয়ার্ক লাগে, আর নেটওয়ার্ক খারাপ হলে টেস্ট অকারণে ব্যর্থ হয়। সমাধান হলো আসল জিনিসের জায়গায় টেস্টের জন্য একটি বদলি বসানো। সিনেমার stunt double-এর নাম থেকে এদের সাধারণ নাম test double. দুই ধরনের সাথে আপনার বেশি দেখা হবে:

Python-এর স্ট্যান্ডার্ড লাইব্রেরিতে unittest.mock আছে (Python 3.3 থেকে)। দুটি ব্যবহার দেখুন:

from unittest.mock import Mock, patch

def test_transfer_sends_one_sms():
    sms = Mock()
    bal = {"rahim": 500, "karim": 0}
    transfer(bal, "rahim", "karim", 200, notify=sms.send)
    sms.send.assert_called_once_with("rahim: sent 200 Tk")

@patch("rates.http_get")            # rates module যে নামে দেখে, সেটি বদলাও
def test_usd_rate(fake_get):
    fake_get.return_value = {"usd": 121.5}
    assert rates.fetch_rate("usd") == 121.5

দ্বিতীয়টি patch: টেস্ট চলার সময় একটি module-এর একটি নাম সাময়িক mock দিয়ে বদলে দেয় (monkeypatch-এর মতোই)। সবচেয়ে চেনা ফাঁদ: patch করতে হয় যেখানে নামটি খোঁজা হয়, যেখানে সংজ্ঞায়িত হয়েছে সেখানে নয়। rates.py-তে from net import http_get লেখা থাকলে patch করুন "rates.http_get", "net.http_get" নয় — কারণ import-এর পরে rates-এর নিজের namespace-এ নামটির একটি আলাদা বাঁধন আছে (পর্ব ২২)।

কেন প্রথমে fake আর dependency injection

Mock-এর সহজলভ্যতা একটি অভ্যাস তৈরি করে: সব কিছু mock করো, আর পরীক্ষা করো কোন method কতবার ডাকা হলো। সমস্যা হলো, তখন টেস্ট যাচাই করে কোড কীভাবে লেখা, কোড কী করে তা নয়। ভেতরের একটি ডাক রিফ্যাক্টর করলেই দশটি টেস্ট ভাঙে, অথচ আচরণ একই। উল্টো দিকে, এত বেশি mock করা যায় যে টেস্ট আসলে শুধু mock-কেই পরীক্ষা করে — আসল কোডের কিছুই নয়।

ভালো অভ্যাস: ফাংশন যেন বাইরের জিনিস (SMS পাঠানোর উপায়, ঘড়ি, রেট আনার ফাংশন) parameter হিসেবে নেয় — অর্থাৎ dependency injection. তাহলে টেস্টে আসলটির বদলে একটি সাধারণ fake দেওয়া যায়, কোনো patch লাগে না। patch রাখুন সেই জায়গার জন্য, যেখানে কোড আপনার হাতে নেই। পরের অংশের runnable প্রোগ্রামে ঠিক এই কৌশল দেখবেন: transfer একটি notify ফাংশন নেয়, আর টেস্ট তাকে দেয় একটি list-এর append — সবচেয়ে সরল fake.

৮ · স্ট্যান্ডার্ড লাইব্রেরির unittest আর doctest

pytest আসার আগে থেকেই Python-এর সাথে আসে unittest — Java-র JUnit-এর আদলে তৈরি (ভাবনার প্রশ্ন ১)। পুরোনো প্রজেক্টে, Python-এর নিজের কোডবেসে আর অনেক কোম্পানির কোডে এটি দেখবেন, তাই পড়তে জানা দরকার। এর ধরন class-ভিত্তিক: টেস্টগুলো একটি TestCase subclass-এর test_ method, প্রস্তুতি setUp-এ, আর যাচাই assertEqual, assertTrue, assertRaises-এর মতো method দিয়ে। ভালো খবর: pytest unittest-এর টেস্টও চালাতে পারে, তাই পুরোনো টেস্ট রেখেই নতুনগুলো pytest-ধাঁচে লেখা যায়।

নিচের runnable প্রোগ্রাম দুটি জিনিস একসাথে দেখায় — unittest-এর গঠন, আর অংশ ৭-এর dependency injection-সহ fake. ব্রাউজারে pytest চলে না, তাই টেস্টগুলো চালানো হয়েছে প্রোগ্রামের ভেতর থেকে, আর ফলের গণনা নিজে ছাপা হয়েছে:

import unittest
def transfer(bal, src, dst, amount, notify):
    if amount <= 0 or bal[src] < amount:
        raise ValueError("insufficient balance or bad amount")
    bal[src] -= amount
    bal[dst] += amount
    notify(f"{src}: sent {amount} Tk")
class TestTransfer(unittest.TestCase):
    def setUp(self):                    # প্রতিটি টেস্টের আগে নতুন করে
        self.bal, self.sms = {"rahim": 500, "karim": 0}, []
    def test_moves_money_and_notifies(self):
        transfer(self.bal, "rahim", "karim", 200, self.sms.append)
        self.assertEqual(self.bal, {"rahim": 300, "karim": 200})
        self.assertEqual(self.sms, ["rahim: sent 200 Tk"])
    def test_insufficient_balance_changes_nothing(self):
        with self.assertRaises(ValueError):
            transfer(self.bal, "rahim", "karim", 900, self.sms.append)
        self.assertEqual((self.bal["rahim"], self.sms), (500, []))

result = unittest.TestResult()
unittest.defaultTestLoader.loadTestsFromTestCase(TestTransfer).run(result)
print(result.testsRun, "tests,", len(result.failures), "failed, OK =", result.wasSuccessful())

একই প্রথম টেস্ট pytest-ধাঁচে কত ছোট, তুলনা করুন — class নেই, self নেই, assertEqual নেই:

def test_moves_money_and_notifies():
    bal, sms = {"rahim": 500, "karim": 0}, []
    transfer(bal, "rahim", "karim", 200, sms.append)
    assert bal == {"rahim": 300, "karim": 200}
    assert sms == ["rahim: sent 200 Tk"]

doctest — ডকুমেন্টেশনের উদাহরণই টেস্ট

docstring-এ অনেকে REPL-এর মতো উদাহরণ লেখেন। doctest module সেই উদাহরণগুলো চালিয়ে দেখে, লেখা ফল আর আসল ফল মেলে কি না:

def grade(marks):
    """০–১০০ নম্বর থেকে লেটার গ্রেড দেয়।

    >>> grade(80)
    'A+'
    >>> grade(32)
    'F'
    >>> grade(101)
    Traceback (most recent call last):
    ValueError: marks must be 0-100, got 101
    """
    ...

python -m doctest grading.py -v (বা pytest --doctest-modules) চালালে উদাহরণগুলো যাচাই হয়। লাভ: ডকুমেন্টেশনের উদাহরণ কখনো মিথ্যা হয়ে পড়ে থাকে না। সীমা: আউটপুট হুবহু মেলাতে হয় (একটি বাড়তি স্পেস, dict-এর ক্রম বা 114.99999999999999-এর মতো float-এর শেষ অঙ্ক বদলালেই ব্যর্থ), আর জটিল প্রস্তুতি লেখা কষ্টকর। তাই doctest ভালো ছোট, উদাহরণধর্মী ফাংশনের জন্য; মূল টেস্ট থাকুক pytest-এ।

৯ · কী টেস্ট করবেন — edge case, coverage, TDD আর CI

pytest শেখা সহজ; কঠিন হলো সিদ্ধান্ত নেওয়া কোন কেসগুলো টেস্ট করবেন। বাগ সাধারণত মাঝখানের সাধারণ ইনপুটে থাকে না — থাকে কিনারায়। প্রতিটি ফাংশনের জন্য এই তালিকাটি মাথায় রাখুন:

Coverage — কোন লাইন কখনো চলেনি

test coverage মাপে, টেস্ট চলার সময় আপনার কোডের কত শতাংশ লাইন অন্তত একবার চলেছে। pytest-cov plugin ইনস্টল করে:

pip install pytest-cov
pytest --cov=pricing --cov-report=term-missing

Name         Stmts   Miss  Cover   Missing
------------------------------------------
pricing.py      18      2    89%   14, 22

সবচেয়ে কাজের অংশ হলো Missing কলাম: লাইন ১৪ আর ২২ কোনো টেস্টে চলেনি — হয়তো ছাড়ের একটি শাখা, বা একটি error-পথ। সেগুলোর জন্য টেস্ট ভাবুন। কিন্তু সীমাটিও জানুন: coverage বলে কোন লাইন চলেছে, বলে না সেটি ঠিক ফল দিয়েছে কি না. একটি টেস্ট সব লাইন চালিয়ে কোনো assert না করলেও ১০০% coverage আসে। আর if marks > 80 লাইনটি ৯০ দিয়ে চালালেও “covered”, অথচ ৮০-র বাগ অধরা। Coverage কম হলে নিশ্চিতভাবে সমস্যা; বেশি হলে নিশ্চিতভাবে কিছুই প্রমাণ হয় না। (--cov-branch দিলে প্রতিটি if-এর দুই দিকই চলেছে কি না দেখে — লাইনের চেয়ে একটু ভালো মাপ।)

TDD — আগে টেস্ট, তারপর কোড

Test-driven development (TDD) ক্রমটি উল্টে দেয়: কোড লেখার আগে একটি ব্যর্থ টেস্ট লিখুন। চক্রটির তিন রং — লাল (নতুন টেস্ট লিখুন, সেটি ব্যর্থ হোক), সবুজ (টেস্ট পাস করানোর মতো সবচেয়ে সরল কোড লিখুন), গোছানো (টেস্ট সবুজ রেখে কোড পরিষ্কার করুন)। তারপর পরের টেস্ট। ফোন-নম্বর ফাংশনে চক্রটি দেখুন:

def test_local_number_unchanged():
    assert parse_phone("01712345678") == "01712345678"
$ pytest  →  F   NameError: name 'parse_phone' is not defined

def parse_phone(raw):
    return raw
$ pytest  →  .   1 passed

def test_country_code_removed():
    assert parse_phone("+8801712345678") == "01712345678"
$ pytest  →  .F   assert '+8801712345678' == '01712345678'

def parse_phone(raw):
    if raw.startswith("+880"):
        raw = raw[3:]
    return raw
$ pytest  →  ..   2 passed

PHONE = re.compile(r"(?:\+?88)?(01[3-9][0-9]{8})")
def parse_phone(raw):
    m = PHONE.fullmatch(raw.replace(" ", ""))
    if not m:
        raise ValueError(f"invalid phone: {raw!r}")
    return m.group(1)
$ pytest  →  ..   2 passed   (তারপর নতুন লাল টেস্ট…)

TDD সবাই সব সময় করেন না, আর করতেই হবে এমনও নয়। কিন্তু দুটি জায়গায় এটি প্রায় সবসময় লাভজনক: বাগ ঠিক করার সময় (আগে বাগটি দেখায় এমন একটি ব্যর্থ টেস্ট, তারপর সমাধান — তাতে নিশ্চিত হন যে আপনি সত্যিই সেই বাগই ঠিক করেছেন), আর যখন প্রতিশ্রুতি পরিষ্কার কিন্তু কোড জটিল (যেমন ফোন নম্বর, VAT-এর নিয়ম, গ্রেডিং)।

Property-based testing — হাজারো ইনপুট নিজে বানানো

এ পর্যন্ত প্রতিটি কেস আপনি নিজে বেছেছেন। property-based testing-এ আপনি লেখেন একটি সাধারণ নিয়ম (property), আর একটি লাইব্রেরি শত শত এলোমেলো ইনপুট বানিয়ে নিয়মটি ভাঙার চেষ্টা করে। Python-এ এর প্রধান লাইব্রেরি hypothesis. যেমন নিয়ম: “যেকোনো বৈধ নম্বর parse_phone-এ দিলে ফল সবসময় ১১ অঙ্কের, 01 দিয়ে শুরু”, বা “parse_phone-এর ফলকে আবার parse_phone-এ দিলে একই ফল”. নিয়ম ভাঙলে hypothesis সবচেয়ে ছোট যে ইনপুটে ভাঙে, সেটি খুঁজে দেখায় (একে বলে shrinking). মানুষ যে অদ্ভুত কেস ভাবতে ভুলে যায় — খালি string, বিশাল সংখ্যা, অদ্ভুত Unicode — তা সে নিজেই খুঁজে আনে।

CI — প্রতিটি পরিবর্তনে টেস্ট নিজে থেকে চলে

টেস্ট শুধু তখনই কাজের, যখন চালানো হয়। continuous integration (CI) মানে প্রতিবার কেউ কোড push করলে বা pull request খুললে একটি সার্ভার নিজে থেকে পুরো test suite চালায়। GitHub-এ এর জন্য আছে GitHub Actions: প্রজেক্টের .github/workflows/ ফোল্ডারে একটি YAML ফাইল, যার মূল কথা মোটামুটি এমন:

on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.14" }
      - run: pip install -e . pytest
      - run: pytest

pytest-এর exit code 1 হলে পুরো কাজটি লাল হয়, আর অনেক দল নিয়ম রাখে — লাল থাকলে কোড মূল শাখায় মেশানো যাবে না। এতে “আমার কম্পিউটারে তো চলছিল” সমস্যাও কমে, কারণ টেস্ট চলে একটি পরিষ্কার, নতুন পরিবেশে।

১০ · AI-এর যুগে — AI-এর লেখা টেস্ট যাচাই করা

“এই ফাংশনের জন্য টেস্ট লিখে দাও” — AI কয়েক সেকেন্ডে বিশটি টেস্ট দেয়, সবগুলো সবুজ। দেখে মনে হয় কাজ শেষ। কিন্তু সবুজ টেস্ট মানেই ভালো টেস্ট নয়। একটি টেস্টের মূল্য হলো বাগ থাকলে সে লাল হবে কি না — আর AI-এর লেখা টেস্টে ঠিক এই গুণটি প্রায়ই অনুপস্থিত। বারবার দেখা যায় এমন সমস্যাগুলো:

অন্যদিকে AI একটি কাজে সত্যিই চমৎকার: edge case ভাবতে সাহায্য করা. “এই ফাংশন কোন কোন ইনপুটে ভাঙতে পারে?” — এই প্রশ্নে AI প্রায়ই এমন কেস তোলে, যা আপনার মাথায় আসেনি। কেসের তালিকা AI-এর কাছ থেকে নিন, প্রত্যাশিত ফল নিজে ঠিক করুন।

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

• প্রতিটি প্রত্যাশিত মান স্পেসিফিকেশনের সাথে নিজে মিলিয়েছি — একটিও “কোড যা দেয় তা-ই” নয়
• কোডে ইচ্ছে করে একটি বাগ ঢুকিয়েছি (>=-কে >, একটি লাইন মুছে) — অন্তত একটি টেস্ট লাল হয়েছে
• খালি, এক, সীমা, অবৈধ আর বাংলা ইনপুট — প্রতিটির অন্তত একটি কেস আছে
• mock শুধু বাইরের সীমানায়; নিজের হিসাবের কোড আসলভাবে চলছে
• assert সুনির্দিষ্ট (== মান), is not None-এর মতো দুর্বল নয়; exception-এর টেস্টে অবস্থা অক্ষত আছে কি না তাও দেখা হয়েছে
• টেস্টগুলো যেকোনো ক্রমে চলে, তারিখ বা এলোমেলো সংখ্যার ওপর নির্ভর করে না