টেস্টিং — কোড ঠিক আছে, প্রমাণ করুন

১ · Test মানে কোডে লেখা প্রতিশ্রুতি

আগের পর্বে (পর্ব ৩১) আপনি debugger আর sanitizer দিয়ে বাগ খুঁজেছেন। Debugging হলো আগুন নেভানো — বাগ চোখে পড়ার পরে তার উৎস খোঁজা। এই পর্বের বিষয় তার উল্টো দিক: এমন ব্যবস্থা বানানো, যাতে বাগ ব্যবহারকারীর কাছে পৌঁছানোর আগেই ধরা পড়ে, আর একবার ঠিক করা বাগ আর কখনো ফিরে না আসে।

একটি দৃশ্য ভাবুন। নাদিয়া একটি ছোট ফলাফল-প্রকাশের প্রোগ্রাম লিখছেন। নম্বর দিলে গ্রেড দেয়। তিনি ৫০ দিলেন — ঠিক এলো। ৯০ দিলেন — ঠিক। “কাজ শেষ!” পরে দেখা গেল, ঠিক ৮০ পাওয়া শিক্ষার্থীরা A পাচ্ছে না, কারণ শর্তে >=-এর বদলে > লেখা। নাদিয়া হাতে কয়েকবার চালিয়েছিলেন, কিন্তু সীমানার মানটি কখনো দেননি। আর পরের সপ্তাহে কোড বদলানোর পর তিনি আবার হাতে চালিয়েও দেখেননি।

হাতে চালিয়ে দেখার দুটি দুর্বলতা আছে। প্রথমত, আমরা সাধারণত সেই ইনপুটই দিই, যেটা কাজ করবে বলে মনে হয়। দ্বিতীয়ত, হাতের পরীক্ষা কোথাও লেখা থাকে না — পরের বার কেউ আর চালায় না। Test এই দুটিই সারায়। একটি test হলো একটি লিখিত প্রতিশ্রুতি: “grade(80) সবসময় 'A' দেবে।” প্রতিশ্রুতিটি কোডে লেখা থাকে, তাই কম্পিউটার যতবার খুশি, এক সেকেন্ডেরও কম সময়ে, ক্লান্তি ছাড়াই যাচাই করতে পারে।

Test লেখার চারটি আসল লাভ

২ · টেস্টিংয়ের ভাষা — unit, integration, end-to-end

প্রতিটি test-এর ভেতরে একই কাঠামো: একটি ইনপুট, আর তার জন্য প্রত্যাশিত ফল। এই জোড়াটিকে বলে test case. প্রত্যাশিত ফলটি আসতে হবে spec থেকে — কোড কী করছে তা দেখে নয়, কোডের কী করার কথা তা থেকে। অনেকগুলো test case মিলে হয় একটি test suite.

Test কতটা বড় অংশ একসাথে পরীক্ষা করছে, সেই অনুযায়ী তিনটি স্তর:

এই তিনটির অনুপাত নিয়ে একটি জনপ্রিয় ছবি আছে — test pyramid. নিচে চওড়া ভিত্তি: অনেক দ্রুত unit test. মাঝে কিছু integration test. চূড়ায় অল্প কয়েকটি end-to-end test. কারণটা সহজ: unit test দ্রুত চলে, আর ফেল করলে ঠিক কোন ফাংশনে সমস্যা তা সাথে সাথে বলে দেয়। End-to-end test বাস্তবের কাছাকাছি, কিন্তু ধীর, আর ফেল করলে শুধু বলে “কোথাও কিছু ভুল।” ধারণাটি জনপ্রিয় করেন Mike Cohn, ২০০৯ সালের একটি বইয়ে।

একটি ভালো test-এর তিন ভাগ — Arrange, Act, Assert

যেকোনো test পড়তে সহজ হয়, যদি সেটি তিন ভাগে সাজানো থাকে। একে বলে Arrange-Act-Assert: আগে পরিস্থিতি সাজান, তারপর একটি কাজ করুন, শেষে ফল যাচাই করুন।

void test_grade_at_80_is_A(void) {
    int marks = 80;              /* Arrange: ইনপুট ও পরিস্থিতি সাজানো */
    char g = grade(marks);       /* Act:     ঠিক একটি কাজ */
    CHECK(g == 'A');             /* Assert:  প্রত্যাশিত ফল যাচাই */
}

নাম পড়েই বোঝা যায় কোন প্রতিশ্রুতি ভাঙলে এটি ফেল করবে। একটি test-এ একটিই আচরণ যাচাই করুন — তাহলে ফেল করলে কারণ খুঁজতে হয় না।

৩ · কোন ইনপুটে টেস্ট করবেন — equivalence class ও boundary

একটি int প্রায় ৪৩০ কোটি রকম মান নিতে পারে। সবগুলো দিয়ে test করা অসম্ভব, আর দরকারও নেই। কৌশলটা হলো ইনপুটকে এমন দলে ভাগ করা, যেখানে একই দলের সবাই একই রকম আচরণ পায়। এই দলকে বলে equivalence class. একই দলের ৫০ আর ৫১ দিয়ে আলাদা test লিখে নতুন কিছু জানা যায় না।

কিন্তু বাগ সবচেয়ে বেশি লুকিয়ে থাকে দলের সীমানায় — যেখানে < আর <=-এর পার্থক্য গুরুত্বপূর্ণ। তাই প্রতিটি সীমানার দুই পাশের মান, অর্থাৎ boundary value, আলাদা করে পরীক্ষা করতে হয়। আমাদের উদাহরণের spec একটি সাধারণ গ্রেডিং নিয়ম (কোনো নির্দিষ্ট বোর্ডের নয়):

নিচের ডায়াগ্রামে দেখুন, এই spec থেকে কীভাবে ধাপে ধাপে test case বাছাই করা হয়:

তিন ধরনের পরিস্থিতি — আর একটি পাঁচ শব্দের চেকলিস্ট

Test case ভাবার সময় তিনটি ঝুড়ি মাথায় রাখুন। Happy path: স্বাভাবিক, প্রত্যাশিত ইনপুট (নম্বর ৬৫)। Edge case: সীমানা বা অস্বাভাবিক কিন্তু বৈধ ইনপুট (ঠিক ০, ঠিক ১০০, খালি তালিকা)। Error case: অবৈধ ইনপুট, যেখানে প্রোগ্রামের কাজ ঠিকভাবে “না” বলা (-১, NULL pointer, না খোলা ফাইল)। AI এবং নতুন প্রোগ্রামার দুজনেই প্রথম ঝুড়িতে থেমে যান।

আর যেকোনো ফাংশনের জন্য এই পাঁচ শব্দের চেকলিস্টটি প্রায় জাদুর মতো কাজ করে:

৪ · নিজের হাতে test harness — CHECK macro

Test চালানোর জন্য কোনো বড় library লাগে না। C-তে মাত্র তিনটি জিনিস দিয়েই একটি কাজের test harness বানানো যায়: শর্ত যাচাইয়ের একটি macro, পাস ও ফেলের দুটি গণনা, আর শেষে ফেল থাকলে শূন্য নয় এমন exit status. পর্ব ২৭-এ শেখা preprocessor-এর তিনটি কৌশল এখানে একসাথে কাজে লাগে।

কেন ফাংশন নয়, macro? ফেল হলে আমরা জানতে চাই কোন লাইনে আর কোন শর্তটি। ফাংশন শুধু 0 বা 1 পায়, শর্তের লেখাটি দেখে না; macro দেখে, কারণ preprocessor লেখার স্তরে কাজ করে। নিচে দেখুন একটি CHECK লাইন আসলে কী হয়ে যায়:

#define CHECK(cond) do { if (cond) passed++; else { failed++; \
    printf("FAIL %s:%d: %s\n", __FILE__, __LINE__, #cond); } } while (0)
...
    CHECK(grade(80) == 'A');

do { if (grade(80) == 'A') passed++; else { failed++;
    printf("FAIL %s:%d: %s\n", __FILE__, __LINE__, #cond); } } while (0);

do { if (grade(80) == 'A') passed++; else { failed++;
    printf("FAIL %s:%d: %s\n", __FILE__, __LINE__, "grade(80) == 'A'"); } } while (0);

do { if (grade(80) == 'A') passed++; else { failed++; printf("FAIL %s:%d: %s\n", "grade_test.c", 17, "grade(80) == 'A'"); } } while (0);

if (quick_mode)
    CHECK(grade(80) == 'A');   /* ; শেষে থাকলেও সমস্যা নেই */
else
    CHECK(grade(100) == 'A');
/* শুধু { ... } দিয়ে লিখলে "};" হয়ে যেত — else একা পড়ে compile error */

$ ./grade_test
FAIL grade_test.c:17: grade(80) == 'A'
7 passed, 1 failed
$ echo $?
1

এবার পুরো জিনিসটি একসাথে চালিয়ে দেখুন। Spec অনুযায়ী লেখা grade() আর অংশ ৩-এর ৮টি boundary test:

#include <stdio.h>

static int passed = 0, failed = 0;
#define CHECK(cond) do { if (cond) passed++; else { failed++; \
    printf("FAIL %s:%d: %s\n", __FILE__, __LINE__, #cond); } } while (0)

char grade(int m) {
    if (m < 0 || m > 100) return 'X';
    if (m >= 80) return 'A';
    if (m >= 33) return 'P';
    return 'F';
}

int main(void) {
    CHECK(grade(0) == 'F');    CHECK(grade(32) == 'F');
    CHECK(grade(33) == 'P');   CHECK(grade(79) == 'P');
    CHECK(grade(80) == 'A');   CHECK(grade(100) == 'A');
    CHECK(grade(-1) == 'X');   CHECK(grade(101) == 'X');
    printf("%d passed, %d failed\n", passed, failed);
    return failed != 0;
}

assert আর CHECK — একই রকম দেখতে, কাজ আলাদা

পর্ব ২৭ ও ৩০-এ আপনি assert দেখেছেন। দুটিই একটি শর্ত যাচাই করে, কিন্তু উদ্দেশ্য সম্পূর্ণ ভিন্ন:

৫ · Test করা যায় এমন কোড — হিসাব আর I/O আলাদা

কিছু কোড test করা খুব সহজ, কিছু প্রায় অসম্ভব। পার্থক্যটা কোডের নকশায়। নিচের ফাংশনটি দেখুন:

/* test করা কঠিন: পড়া, হিসাব, ছাপা — সব এক জায়গায় */
void print_grade(void) {
    int m;
    scanf("%d", &m);
    if (m >= 80) printf("A\n");
    else if (m >= 33) printf("P\n");
    else printf("F\n");
}

এটিকে test করতে হলে কাউকে কীবোর্ডে বসে নম্বর টাইপ করতে হবে, তারপর স্ক্রিন পড়তে হবে। হিসাবের নিয়মটি I/O-র ভেতরে বন্দি। সমাধান হলো আলাদা করা: হিসাব থাকবে একটি pure function-এ — একই ইনপুটে সবসময় একই ফল, কোনো side effect নেই — আর পড়া-ছাপা থাকবে বাইরের একটি পাতলা স্তরে। তখন grade()-কে একশোবার ডেকে test করা যায়, কীবোর্ড ছাড়াই। পর্ব ২৯-এ দোকানের খাতা মডিউলে কোনো printf বা scanf রাখেননি — সেটি এই কারণেই।

যা বদলায়, তা বাইরে থেকে দিন — dependency injection-এর সহজ রূপ

কিছু ফাংশন এমন জিনিসের ওপর নির্ভর করে, যা প্রতিবার বদলায়: বর্তমান সময়, random সংখ্যা, ফাইল, নেটওয়ার্ক। ধরুন একটি bKash-ধাঁচের OTP দুই মিনিট পর বাতিল হয়। ফাংশনটি ভেতরে নিজেই time(NULL) ডাকলে test করতে আপনাকে সত্যিই দুই মিনিট অপেক্ষা করতে হবে! উপায় হলো নির্ভরতাটি বাইরে থেকে পাঠানো — একে বলে dependency injection. C-তে এর সবচেয়ে সহজ রূপ হলো পর্ব ২৮-এ শেখা function pointer বা callback:

typedef long (*clock_fn)(void);          /* "এখন কত সেকেন্ড" জানার ফাংশন */

int otp_valid(long issued_at, clock_fn now) {
    return now() - issued_at <= 120;     /* ১২০ সেকেন্ড পর্যন্ত বৈধ */
}

/* আসল প্রোগ্রামে: otp_valid(t, real_clock)  — real_clock ভেতরে time() ডাকে */
/* test-এ: নকল ঘড়ি, যার সময় আমরাই ঠিক করি */
static long fake_t;
static long fake_clock(void) { return fake_t; }
/* fake_t = 1120; CHECK(otp_valid(1000, fake_clock) == 1);   ঠিক ১২০ সেকেন্ড */
/* fake_t = 1121; CHECK(otp_valid(1000, fake_clock) == 0);   এক সেকেন্ড বেশি  */

এই নকল ঘড়ির মতো আসল জিনিসের বিকল্পকে বলে test double — কখনো mock, কখনো stub বা fake নামে ডাকা হয়। একই কৌশল ফাইলের জন্যও: ফাংশন নিজে fopen না করে একটি FILE * নেবে। আসল প্রোগ্রাম পাঠাবে stdin বা সত্যিকারের ফাইল; test পাঠাবে tmpfile() দিয়ে বানানো একটি অস্থায়ী ফাইল, যাতে আগেই নির্দিষ্ট লেখা রাখা আছে।

পুরো CLI প্রোগ্রাম test করা — run(argc, argv)

পর্ব ২৫-এর কমান্ড-লাইন টুলগুলো কীভাবে test করবেন? কৌশলটা হলো main-কে প্রায় খালি রাখা, আর আসল কাজ একটি run ফাংশনে সরিয়ে নেওয়া:

int run(int argc, char **argv, FILE *out, FILE *err);   /* সব কাজ এখানে */

int main(int argc, char **argv) {
    return run(argc, argv, stdout, stderr);             /* main শুধু জোড়া দেয় */
}

/* test: char *args[] = {"shop", "add", "-5", NULL};
         CHECK(run(3, args, out, err) == 2);   ঋণাত্মক টাকা → usage error */

এখন test নিজেই নকল argv বানিয়ে run ডাকে, আউটপুট অস্থায়ী ফাইলে ধরে মেলায়, আর exit code যাচাই করে — নতুন প্রসেস চালানোর ঝামেলা ছাড়াই।

৬ · TDD — আগে test, তারপর কোড

সাধারণত আমরা আগে কোড লিখি, তারপর (যদি সময় থাকে) test. Test-driven development (TDD) এই ক্রম উল্টে দেয়। তিন ধাপের একটি ছোট চক্র, বারবার:

একটি পরিচিত উদাহরণে চক্রটি দেখুন: অধিবর্ষ বা leap year যাচাই। নিয়ম — ৪ দিয়ে বিভাজ্য হলে অধিবর্ষ, কিন্তু ১০০ দিয়ে বিভাজ্য হলে নয়, তবে ৪০০ দিয়ে বিভাজ্য হলে আবার অধিবর্ষ। তাই ২০২৪ অধিবর্ষ, ১৯০০ নয়, ২০০০ অধিবর্ষ।

int is_leap(int y) { (void)y; return 0; }

FAIL 2024: want 1, got 0
1/2 tests passed

int is_leap(int y) { return y % 4 == 0; }

2/2 tests passed

int is_leap(int y) { return y % 4 == 0; }

FAIL 1900: want 0, got 1
2/3 tests passed

int is_leap(int y) { return y % 4 == 0 && y % 100 != 0; }

3/3 tests passed

int is_leap(int y) { return y % 4 == 0 && y % 100 != 0; }

FAIL 2000: want 1, got 0
3/4 tests passed

int is_leap(int y) {
    return (y % 4 == 0 && y % 100 != 0) || y % 400 == 0;
}

4/4 tests passed

int is_leap(int y) {
    if (y % 400 == 0) return 1;   /* ২০০০ */
    if (y % 100 == 0) return 0;   /* ১৯০০ */
    return y % 4 == 0;            /* ২০২৪, ২০২৩ */
}

4/4 tests passed

নিচের প্রোগ্রামে stepper-এর ধাপ ৪-এর কোডটি রাখা হয়েছে, কিন্তু এবার পুরো test table-সহ — একটি টেবিলে বছর আর প্রত্যাশিত ফল, আর একটি লুপ সবগুলো যাচাই করে। একে বলে table-driven test. চালিয়ে দেখুন কোনটি ফেল করে:

#include <stdio.h>

int is_leap(int y) {          /* BUG on purpose: the 400 rule is missing */
    return y % 4 == 0 && y % 100 != 0;
}

int main(void) {
    struct { int year, want; } t[] = {
        {2024, 1}, {2023, 0}, {1900, 0}, {2000, 1}, {2100, 0}
    };
    int n = sizeof t / sizeof t[0], failed = 0;
    for (int i = 0; i < n; i++) {
        int got = is_leap(t[i].year);
        if (got != t[i].want) {
            printf("FAIL year %d: want %d, got %d\n", t[i].year, t[i].want, got);
            failed++;
        }
    }
    printf("%d/%d tests passed\n", n - failed, n);
    return failed != 0;
}

প্রতিটি বাগের জন্য একটি regression test

পর্ব ৩১-এ debugger দিয়ে বাগ খুঁজে ঠিক করেছেন। কিন্তু পেশাদার কাজ সেখানে শেষ নয়। নিয়মটি হলো: ঠিক করার আগে এমন একটি test লিখুন যা বাগটির কারণে ফেল করে, তারপর কোড ঠিক করুন, তারপর test-টি চিরদিনের জন্য suite-এ রেখে দিন। একে বলে regression test. ছয় মাস পর কেউ — আপনি, সহকর্মী বা AI — একই ভুল আবার করলে সাথে সাথে লাল হবে।

৭ · উদাহরণের বাইরে — property, fuzzing, stress আর coverage

এতক্ষণের সব test ছিল উদাহরণ-ভিত্তিক: “এই ইনপুটে এই ফল।” এর একটি মৌলিক সীমা আছে — আপনি যে ইনপুটের কথা ভাবেননি, তার test-ও লেখেননি। আর বাগ লুকিয়ে থাকে ঠিক সেখানেই। নিচের কৌশলগুলো যন্ত্রকে দিয়ে নতুন ইনপুট বানিয়ে নেয়।

Property-based testing — নির্দিষ্ট উত্তর নয়, নিয়ম

অনেক সময় প্রতিটি ইনপুটের সঠিক উত্তর হাতে জানা থাকে না, কিন্তু উত্তরটি কোন নিয়ম মানবে তা জানা থাকে। Property-based testing-এ আপনি নিয়মটি লেখেন, আর যন্ত্র হাজার হাজার এলোমেলো ইনপুট বানিয়ে যাচাই করে। কয়েকটি উদাহরণ:

• is_leap(y) == is_leap(y + 400) — যেকোনো বছরের জন্য, কারণ গ্রেগরিয়ান ক্যালেন্ডার প্রতি ৪০০ বছরে পুনরাবৃত্তি হয়।
• বৈধ a <= b হলে grade(a) কখনো grade(b)-এর চেয়ে ভালো হবে না — বেশি নম্বরে খারাপ গ্রেড অসম্ভব।
• যেকোনো sort ফাংশনের ফল সাজানো থাকবে, আর তাতে ঠিক আগের উপাদানগুলোই থাকবে — একটিও হারাবে না, নতুন আসবে না।

ধারণাটি জনপ্রিয় করে Haskell ভাষার QuickCheck (২০০০ সালের দিকে)।

Fuzzing — যন্ত্রকে দিয়ে আবর্জনা ইনপুট খাওয়ানো

Fuzzing হলো প্রোগ্রামকে লক্ষ লক্ষ অদ্ভুত, ভাঙাচোরা, অপ্রত্যাশিত ইনপুট দেওয়া, আর দেখা কোনটিতে সে crash করে বা sanitizer অভিযোগ করে। এখানে “সঠিক উত্তর” জানার দরকারই নেই — প্রশ্ন একটিই: প্রোগ্রাম কি ভেঙে পড়ল? আধুনিক fuzzer যেমন AFL আর libFuzzer অন্ধভাবে এলোমেলো নয়; তারা দেখে কোন ইনপুট কোডের নতুন কোনো পথ খুলল, আর সেই ইনপুট থেকে আরও নতুন ইনপুট বানায়। নিচে দেখুন একটি fuzzer কীভাবে একটি লুকানো buffer overflow খুঁজে পায়:

Rafi:80
Mitu:95
/* ভেতরে: char name[16]; strcpy(r->name, ...); — বাগটি এখানে লুকানো */

Rafi:8
Raf:80
Rafi::80
:80
RafiRafi:80
R\xff\x00fi:80

#1024   NEW  cov: 31  "RafiRafi:80"      <- লম্বা নাম, নতুন পথ
#5120   NEW  cov: 33  "RafiRafiRafi:80"
#9000   ---  cov: 33  "Rafi:8"           <- নতুন কিছু নেই, বাদ

ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 23 ... in strcpy
    #1 in parse_record record.c:9
input: "RafiRafiRafiRafiRafiRa:80"

AAAAAAAAAAAAAAAA:1      <- ঠিক ১৬ অক্ষর: NUL-এর জায়গা নেই

/* regression: fuzzer crash, 16-char name */
CHECK(parse_record("AAAAAAAAAAAAAAAA:1", &r) == -1);
CHECK(parse_record("AAAAAAAAAAAAAAA:1", &r) == 0);   /* ১৫ — চলবে */

libFuzzer-এ একটি fuzz target লেখা খুবই সহজ — একটি ফাংশন, যা বাইটের একটি টুকরো নিয়ে আপনার কোডকে খাওয়ায়:

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    char line[64];
    if (size >= sizeof line) return 0;
    memcpy(line, data, size);
    line[size] = '\0';              /* fuzzer-এর বাইটকে string বানানো */
    struct record r;
    parse_record(line, &r);         /* crash হলে fuzzer থেমে ইনপুট সেভ করবে */
    return 0;
}

clang -g -fsanitize=fuzzer,address fuzz_record.c record.c -o fuzz_record
./fuzz_record corpus/

Stress testing — brute force-এর সাথে মিলিয়ে দেখা

Fuzzing প্রশ্ন করে “crash করল কি?” কিন্তু প্রোগ্রাম crash না করেও ভুল উত্তর দিতে পারে। তখন দরকার একটি তুলনা: একটি ধীর কিন্তু নিশ্চিতভাবে সঠিক brute force সমাধান, আর আপনার দ্রুত সমাধান — দুটোকে একই এলোমেলো ইনপুট দিয়ে উত্তর মেলানো। এটি stress testing, যা পর্ব ৪৪-এ হাতে-কলমে করবেন।

Code coverage — test আসলে কোন লাইনগুলো চালাল

Code coverage মাপে আপনার test চলার সময় কোডের কত অংশ অন্তত একবার চলেছে। GCC-র সাথেই আসে gcov:

gcc --coverage -O0 grade_test.c -o grade_test
./grade_test
gcov grade_test.c          # grade_test.c.gcov ফাইলে প্রতিটি লাইন কতবার চলল

ধরুন আপনি ০ আর ৩২-এর test দুটি বাদ দিয়েছেন। রিপোর্টে grade()-এর অংশটি এমন দেখাবে — বাঁ পাশের সংখ্যা হলো লাইনটি কতবার চলেছে:

        6:    7:char grade(int m) {
        6:    8:    if (m < 0 || m > 100) return 'X';
        4:    9:    if (m >= 80) return 'A';
        2:   10:    if (m >= 33) return 'P';
    #####:   11:    return 'F';

##### মানে এই লাইন একবারও চলেনি — “ফেল” পথটি কোনো test ছোঁয়নি। Coverage-এর আসল কাজ এটাই: কোথায় test নেই তা দেখানো। একটু সূক্ষ্ম রূপ হলো branch coverage — প্রতিটি if-এর সত্য আর মিথ্যা, দুটি পথই চলেছে কি না।

৮ · Framework, make test আর CI — test-কে অভ্যাসে পরিণত করা

আমাদের CHECK harness ছোট প্রজেক্টে যথেষ্ট। বড় প্রজেক্টে মানুষ তৈরি test framework ব্যবহার করে — test নিজে খুঁজে চালানো, প্রত্যাশিত আর আসল মান পাশাপাশি দেখানো, crash সামলানো, mock বানানোর সুবিধাসহ।

make test — একটি কমান্ডে সব test

পর্ব ২৯-এর Makefile-এ একটি নতুন target যোগ করুন। তাহলে যে কেউ — নতুন সহকর্মী, আপনি নিজে ছয় মাস পরে, বা CI সার্ভার — শুধু make test লিখেই সব test চালাতে পারবে। Test build-এ sanitizer চালু রাখা ভালো অভ্যাস, যাতে পর্ব ৩১-এর মেমরি-ভুলগুলোও test চলার সময়েই ধরা পড়ে:

CC     = gcc
CFLAGS = -Wall -Wextra -g -fsanitize=address,undefined

test: tests/test_grade
	./tests/test_grade

tests/test_grade: tests/test_grade.c grade.c grade.h
	$(CC) $(CFLAGS) tests/test_grade.c grade.c -o $@

.PHONY: test

এখানেই আমাদের return failed != 0; লাইনের গুরুত্ব। Make একটি কমান্ডের exit code শূন্য না পেলে থেমে যায় আর “Error” দেখায়। অর্থাৎ একটি test ফেল করলে make test নিজেই ব্যর্থ হয় — আলাদা করে আউটপুট পড়তে হয় না।

CI — প্রতিবার push করলেই test

সবচেয়ে বড় ধাপ হলো test চালানোর দায়িত্ব মানুষের হাত থেকে সরিয়ে যন্ত্রের হাতে দেওয়া। Continuous Integration (CI)-এ প্রতিবার কেউ git-এ কোড push করলে একটি সার্ভার নিজে থেকেই build করে, সব test চালায়, আর ফেল করলে লাল চিহ্ন দেখায় — কোড মূল শাখায় মেশানোর আগেই। GitHub-এ এর জন্য শুধু একটি ছোট ফাইল লাগে:

name: test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make test

এরপর থেকে প্রতিটি পরিবর্তন — আপনার হোক, সহকর্মীর হোক বা AI-এর — একই কঠোর পরীক্ষার মধ্য দিয়ে যাবে, ঝিমিয়ে পড়া বা ভুলে যাওয়ার সুযোগ নেই। পেশাদার দলে একটি সাধারণ নিয়ম: “CI লাল থাকলে কেউ নতুন কিছু merge করবে না।” CI ও deployment-এর পুরো জগৎ দেখতে পারবেন Cloud & DevOps কোর্সে, আর git ও দলগত কাজের নিয়ম Software Engineering & Git কোর্সে।

৯ · AI-এর যুগে টেস্টিং — যে কোড আপনি লেখেননি

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

/* ফাঁদ ১: tautological — কখনো ফেল করতে পারে না */
CHECK(grade(85) == grade(85));

/* ফাঁদ ২: implementation-এর নকল — কোডের ভুলও নকল হয়ে আসে */
CHECK(is_leap(2000) == (2000 % 4 == 0 && 2000 % 100 != 0));

/* ফাঁদ ৩: শুধু happy path — সীমানা আর অবৈধ ইনপুট নেই */
CHECK(grade(50) == 'P');  CHECK(grade(90) == 'A');

প্রথমটিকে বলে tautological test — সংজ্ঞা অনুযায়ীই সত্য। দ্বিতীয়টি কোডের ভুল সূত্রটিই প্রত্যাশিত ফল হিসেবে কপি করেছে। তৃতীয়টি নাদিয়ার সেই পুরোনো ভুল — সীমানা থেকে দূরের মান। তিনটিই পাস করবে, আর আপনি ভাববেন সব ঠিক।

Test-কেই test করা — mutation testing

Test কতটা শক্ত, মাপার একটি চমৎকার উপায়: কোডে ইচ্ছা করে ছোট বাগ ঢোকান — >=-কে >, &&-কে || — আর দেখুন test ফেল করে কি না। প্রতিটি বদলানো সংস্করণ একটি mutant. Test ফেল করলে mutant “মারা গেল” — ভালো; পাস করলে “বেঁচে গেল” — মানে test এই ভুল ধরতে পারে না। এই পদ্ধতি mutation testing, ধারণাটি ১৯৭০-এর দশকের। m >= 80-কে m > 80 করলে ফাঁদ ৩-এর test বেঁচে যায়, কিন্তু অংশ ৪-এর boundary test সাথে সাথে মেরে ফেলে।

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

• প্রতিটি প্রত্যাশিত ফল আমি নিজে spec থেকে মিলিয়েছি — কোড দেখে নয়
• কোনো test-এ ফাংশনের সূত্র নকল করা নেই, আর x == x ধরনের সবসময়-সত্য শর্ত নেই
• প্রতিটি সীমানার দুই পাশ, আর অবৈধ ইনপুট (ঋণাত্মক, NULL, খালি) আছে
• কোডে ইচ্ছা করে একটি >= বদলে দেখেছি — অন্তত একটি test লাল হয়েছে
• AI কোনো test পাস করাতে গিয়ে test-এর প্রত্যাশিত মানই বদলে দেয়নি — test ফাইলের পরিবর্তন আলাদা করে পড়েছি
• Test ফেল করলে exit code শূন্য নয়, আর test-গুলো sanitizer চালু রেখেও পাস করে

শেষ একটি সতর্কতা: AI মাঝে মাঝে প্রত্যাশাই ভুল লেখে — যেমন “১৯০০ অধিবর্ষ।” তখন test ফেল করে, আর AI সঠিক কোডটিকেই “ঠিক” করতে গিয়ে নষ্ট করে ফেলে। তাই test-এর প্রতিটি প্রত্যাশিত মান মানুষের চোখে একবার যাচাই হওয়া চাই — ঠিক যেমন খাতা দেখার আগে উত্তরমালাটিই নির্ভুল হতে হয়।

১০ · মডিউল ৪-এর সমাপ্তি — বড় প্রোগ্রাম সাজানোর টুলবক্স

এই পর্বের সাথে মডিউল ৪ শেষ হলো। মডিউলের শুরুতে আপনার প্রোগ্রাম ছিল একটি ফাইলের, যা চালালে কিছু ছাপে আর শেষ হয়ে যায়। এখন আপনার হাতে আছে এমন প্রোগ্রাম বানানোর সব হাতিয়ার, যা ডেটা জমায়, কমান্ড-লাইন থেকে নির্দেশ নেয়, কয়েকটি মডিউলে ভাগ থাকে, ভুলের জন্য প্রস্তুত থাকে — আর নিজের সঠিকতা প্রমাণ করতে পারে।

খেয়াল করুন, আজকের পর্বে আগের প্রায় সবকটি পর্ব একসাথে কাজ করেছে: macro (২৭) দিয়ে harness, function pointer (২৮) দিয়ে নকল নির্ভরতা, Makefile (২৯) দিয়ে make test, exit code (২৫) দিয়ে CI-কে খবর, sanitizer (৩১) দিয়ে লুকানো মেমরি-ভুল। মডিউল ৫-এ নিজ হাতে linked list, stack, tree, hash table বানাবেন, যেখানে একটি ভুল pointer পুরো কাঠামো ভেঙে দেয়। প্রতিটির সাথে test লিখুন — খালি, একটি, অনেক উপাদান।