টেস্টিং ও ডিবাগিং — প্রমাণ দিয়ে কোডে ভরসা, পদ্ধতি দিয়ে বাগ খোঁজা

১ · টেস্ট মানে চালানো যায় এমন প্রতিশ্রুতি

এই কোর্সে আপনি অনেক প্রোগ্রাম লিখেছেন। প্রতিবার লেখার পর কী করেছেন? চালিয়ে দেখেছেন, স্ক্রিনে ফল দেখে মনে মনে বলেছেন “হ্যাঁ, ঠিক আছে।” এই কাজটিই আসলে একটি টেস্ট — শুধু সমস্যা হলো, সেটি আপনার মাথায় ছিল, কোডে নয়। পরের সপ্তাহে কোড বদলালে আবার হাতে চালাতে হবে, আবার মনে করতে হবে কোন ফল ঠিক। দশটি ফাংশন হলে কাজটি বিরক্তিকর, এক হাজারটি হলে অসম্ভব।

স্বয়ংক্রিয় টেস্ট সেই “মনে মনে যাচাই”-কে কোডে লিখে ফেলে: “discounted(100000) ডাকলে ফল হবে 90000.” এটি একটি চালানো যায় এমন প্রতিশ্রুতি। যতবার খুশি, যেকোনো মেশিনে, এক সেকেন্ডের কম সময়ে মেশিন নিজেই যাচাই করে দেয় প্রতিশ্রুতিটি এখনো রাখা হচ্ছে কি না। সবচেয়ে ছোট এই ধরনের যাচাইয়ের নাম unit test — একটি ফাংশন বা class-কে আলাদা করে পরীক্ষা।

টেস্ট লেখার তিনটি বড় কারণ আছে, আর তিনটিই সময়ের সাথে বাড়ে:

এই পর্বের দ্বিতীয় অর্ধেক অন্য দিক থেকে আসে। টেস্ট যখন লাল হয়, বা ব্যবহারকারী জানান “রিপোর্ট crash করছে”, তখন কারণ খুঁজতে হয়। এর নাম ডিবাগিং, আর এটি অনুমানের খেলা নয়, একটি পদ্ধতি — ঠিক বিজ্ঞানের পরীক্ষাগারের মতো: পর্যবেক্ষণ, অনুমান, পরীক্ষা, পরিসর ছোট করা। টেস্টিং আর ডিবাগিং একই মুদ্রার দুই পিঠ: টেস্ট বাগকে সামনে আনে, ডিবাগিং তার শিকড় খোঁজে, আর শেষে একটি নতুন টেস্ট সেই শিকড়কে চিরকালের জন্য পাহারা দেয়।

২ · টেস্টিং পিরামিড আর একটি টেস্টের তিন অংশ

সব টেস্ট এক রকম নয়। একটি দোকানের সফটওয়্যারের কথা ভাবুন — ছাড়ের হিসাব, কার্ট, ডেটাবেস, আর ব্রাউজারে পুরো কেনাকাটা। কোনটি কীভাবে পরীক্ষা করবেন, তার একটি পরিচিত নকশা আছে, যার নাম testing pyramid:

পিরামিডের আকৃতির কারণ সরল: নিচের টেস্ট দ্রুত, স্থির, আর ব্যর্থ হলে ঠিক কোন ফাংশনে সমস্যা তা সাথে সাথে বলে দেয়। ওপরের টেস্ট বাস্তবের কাছাকাছি, কিন্তু ধীর, ভঙ্গুর, আর ব্যর্থ হলে শুধু বলে “কোথাও কিছু ভুল।” তাই বেশিরভাগ যাচাই নিচে রাখুন, আর ওপরে শুধু এটুকু নিশ্চিত করুন যে অংশগুলো একসাথে জোড়া লাগে। উল্টো আকৃতি — শুধু ধীর end-to-end টেস্ট — দলগুলো মজা করে “আইসক্রিম কোন” বলে, আর সেখানে টেস্ট চালাতে এত সময় লাগে যে কেউ চালায় না।

একটি unit test-এর শরীর — Arrange, Act, Assert

প্রায় প্রতিটি ভালো unit test তিনটি অংশে ভাগ করা যায়, যার নাম Arrange–Act–Assert: আগে অবস্থা সাজানো, তারপর ঠিক একটি কাজ করা, শেষে ফল যাচাই। প্রতিটি টেস্টের একটি স্পষ্ট নাম থাকে, যা একটি আচরণ বর্ণনা করে — এক কথায় একটি test case. নিয়মটি হলো: দোকানে ১০০০ টাকা বা বেশি কেনাকাটায় ১০% ছাড়। টাকা আমরা পয়সায় রাখছি (১ টাকা = ১০০ পয়সা), যাতে double-এর দশমিক ভুল না আসে। ধাপে ধাপে দেখুন:

1void discount_on_exact_boundary() {2    // Arrange: exactly 1000 Tk3    long long price = 100'000;  // poisha4    // Act: one call, nothing else5    long long got = discounted(price);6    // Assert: compare with the promise7    CHECK(got == 90'000);8}

৩ · Framework ছাড়া প্রথম টেস্ট — assert আর ছোট CHECK macro

টেস্ট লিখতে কোনো বড় টুল লাগে না। সবচেয়ে সরল যন্ত্রটি standard library-তেই আছে: <cassert>-এর assert. assert(discounted(0) == 0); লিখলে শর্ত মিথ্যা হলে প্রোগ্রাম ফাইলের নাম, লাইন আর শর্তটি ছাপিয়ে থেমে যায়। কিন্তু টেস্টের কাজে এর দুটি দুর্বলতা আছে। এক, প্রথম ব্যর্থতাতেই সব থামে — বাকি নয়টি টেস্টের খবর পাওয়া যায় না। দুই, NDEBUG macro সংজ্ঞায়িত থাকলে (অনেক release build-এ থাকে) সব assert নিঃশব্দে উধাও হয়, তাই টেস্ট আসলে কিছুই যাচাই করে না।

সমাধান: নিজের একটি ছোট test harness — যে কোড টেস্ট চালায়, পাস-ফেল গোনে আর ব্যর্থতার জায়গা জানায়। নিচে মাত্র কয়েক লাইনে একটি। পর্ব ৪২-এর std::source_location দিয়ে লাইন নম্বর আসে, আর একটি ছোট macro শর্তটিকে লেখা হিসেবেও ধরে রাখে (#expr মানে “শর্তটির লেখা রূপ”)। পরীক্ষার বিষয় দোকানের ছাড়, আর প্রতিটি টেস্ট একটি করে edge case:

#include <print>
#include <source_location>

int passed = 0, failed = 0;
void check(bool ok, const char* what,
           std::source_location loc = std::source_location::current()) {
    if (ok) { ++passed; return; }
    ++failed; std::println("FAIL line {}: {}", loc.line(), what);
}
#define CHECK(expr) check((expr), #expr)

long long discounted(long long p) {   // poisha; 10% off from 1000 Tk
    if (p < 0) return -1;               // invalid input
    return p >= 100'000 ? p - p / 10 : p;
}
int main() {
    CHECK(discounted(0) == 0);                    // empty cart
    CHECK(discounted(99'999) == 99'999);          // just below
    CHECK(discounted(100'000) == 90'000);         // on the boundary
    CHECK(discounted(-500) == -1);                // invalid
    CHECK(discounted(5'000'000'000) == 4'500'000'000);  // very large
    std::println("{} passed, {} failed", passed, failed);
    return failed == 0 ? 0 : 1;
}

এখানে টেস্টগুলো কোন ইনপুট বেছেছে, সেটিই আসল শিক্ষা। 99'999 আর 100'000 — সীমানার দুই পাশ। 0 — খালি কার্ট। -500 — অবৈধ ইনপুট। পাঁচ কোটি টাকা (৫০০ কোটি পয়সা) — int-এর সীমা ছাড়ানো বিশাল মান, যেখানে টাইপ ছোট হলে overflow হতো (পর্ব ৪৩)। এলোমেলো দশটি সংখ্যা পরীক্ষা করার চেয়ে এই পাঁচটি অনেক বেশি কাজের। অংশ ৫-এ এর পুরো চেকলিস্ট দেখবেন।

৪ · Test framework — GoogleTest, Catch2 আর doctest

নিজের harness দিয়ে শেখা ভালো, কিন্তু বাস্তব প্রজেক্টে একটি test framework ব্যবহার হয়। এটি আপনার CHECK-এর মতোই, সাথে অনেক সুবিধা: প্রতিটি টেস্ট আলাদা নামে নিবন্ধন, ব্যর্থ হলে দুই পাশের মান ছাপানো, নাম দিয়ে বাছাই করে চালানো, exception যাচাই, আর CI-র জন্য XML রিপোর্ট। C++-এ তিনটি framework সবচেয়ে পরিচিত। নিচের কোডগুলো চালানোর জন্য নয় — এগুলোর জন্য library ইনস্টল করে link করতে হয় (পর্ব ৪৭-এর CMake দিয়ে)।

#include <gtest/gtest.h>

TEST(Discount, AppliesFromThousandTaka) {
    EXPECT_EQ(discounted(100'000), 90'000);
    EXPECT_EQ(discounted(99'999), 99'999);
}

class CartTest : public ::testing::Test {
protected:
    Cart cart;                         // fresh for every TEST_F
    void SetUp() override { cart.add({"Rice", 8'000, 5}); }
};

TEST_F(CartTest, TotalOfOneLine) {
    ASSERT_EQ(cart.size(), 1u);        // stop if setup failed
    EXPECT_EQ(cart.total(), 40'000);
}

#include <catch2/catch_test_macros.hpp>   // Catch2 v3

TEST_CASE("discount starts at 1000 Tk", "[shop]") {
    REQUIRE(discounted(100'000) == 90'000);
    CHECK(discounted(99'999) == 99'999);
}

TEST_CASE("cart total", "[shop]") {
    Cart cart;                     // re-run for each SECTION
    SECTION("empty cart is zero") {
        REQUIRE(cart.total() == 0);
    }
    SECTION("one line") {
        cart.add({"Rice", 8'000, 5});
        REQUIRE(cart.total() == 40'000);
    }
}

#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include <doctest/doctest.h>

TEST_CASE("discount boundary") {
    CHECK(discounted(100'000) == 90'000);
    CHECK_THROWS_AS(parse_money("12.5.0"), std::invalid_argument);
}

৫ · টেস্ট করা যায় এমন নকশা — আর edge case-এর চেকলিস্ট

অনেকে বলেন “আমার কোড টেস্ট করা কঠিন।” প্রায় সবসময় এর মানে, কোডের নকশায় সমস্যা আছে। যে ফাংশন নিজেই ফাইল খোলে, ঘড়ি দেখে, random সংখ্যা বানায়, global ভ্যারিয়েবল বদলায় আর স্ক্রিনে লেখে — তাকে আলাদা করে পরীক্ষা করার কোনো উপায় নেই। Testability তাই নকশার একটি গুণ, আর তার চারটি সরল নিয়ম আছে।

1. হিসাবকে pure function বানান। একই ইনপুটে সবসময় একই ফল, কোনো side effect নেই। discounted(long long) এমনই — টেস্ট করতে কিছু সাজাতে হয় না। ফাইল পড়া, হিসাব করা আর ছাপানো তিনটি আলাদা ফাংশনে রাখুন; মাঝেরটিই সবচেয়ে বেশি টেস্ট পায়।
2. বাইরের জিনিস interface দিয়ে দিন। পর্ব ২৬-এ দেখেছেন, OrderService শুধু একটি Notifier& চেনে, আর টেস্টে আমরা SMS-এর বদলে একটি FakeNotifier দিয়েছিলাম। এটাই dependency injection, আর fake-টি একটি test double. ডেটাবেস, নেটওয়ার্ক, পেমেন্ট গেটওয়ে — সবকিছুর জন্য একই কৌশল। যে test double মনে রাখে কে কোন argument দিয়ে কতবার ডাকল, তাকে বলে mock; GoogleTest-এর সঙ্গী gMock এগুলো বানাতে সাহায্য করে।
3. সময় আর random-কে বাইরে থেকে দিন। “রাত ১২টার পরে অর্ডারে ডেলিভারি চার্জ দ্বিগুণ” — এই নিয়ম ফাংশনের ভেতরে system_clock::now() ডাকলে টেস্ট করতে আপনাকে মাঝরাত পর্যন্ত জেগে থাকতে হবে। পর্ব ৪১-এর ঘড়ি আর random engine প্যারামিটার হিসেবে নিন। টেস্টে একটি স্থির সময়, আর একটি নির্দিষ্ট seed.
4. লুকোনো global অবস্থা নয়। global variable-এ রাখা অবস্থা এক টেস্ট থেকে আরেক টেস্টে চুইয়ে পড়ে, আর টেস্টের ক্রম বদলালে ফল বদলায়। উপরের harness-এর passed/failed ব্যতিক্রম, কারণ সেগুলো শুধু গণনা — যাচাই করা কোডের অংশ নয়।

// কঠিন: ভেতরে লুকোনো ঘড়ি
long long delivery_fee(long long base) {
    auto now = std::chrono::system_clock::now();   // টেস্ট নিয়ন্ত্রণ করতে পারে না
    ...
}
// সহজ: সময় বাইরে থেকে আসে
long long delivery_fee(long long base, std::chrono::hours hour_of_day);
// টেস্ট: CHECK(delivery_fee(6'000, 23h) == 6'000);
//        CHECK(delivery_fee(6'000, 0h)  == 12'000);

Edge case-এর ছয় ঘর — parse_money দিয়ে

ধরুন দোকানের একটি ফাংশন ব্যবহারকারীর লেখা দাম পড়ে পয়সায় রূপান্তর করে: parse_money("12.50") ফেরত দেয় 1250. কোন কোন ইনপুটে টেস্ট লিখবেন? বাগ সাধারণত সাধারণ ইনপুটে নয়, কিনারায় থাকে — এদের নাম edge case. প্রায় যেকোনো ফাংশনের জন্য ছয়টি ঘর মনে রাখুন:

অবৈধ ইনপুটে কী হবে, সেটি টেস্ট লেখার আগেই ঠিক করতে হয় — exception (পর্ব ৩৭), নাকি std::expected, নাকি std::optional (পর্ব ৩৮)। টেস্ট লিখতে গিয়ে প্রায়ই দেখা যায় এই সিদ্ধান্তটি কেউ নেয়নি। এটিও টেস্টের একটি উপকার: অস্পষ্ট নিয়ম সামনে চলে আসে।

৬ · TDD, property, fuzzing — আর CTest, CI ও coverage

Test-driven development — আগে টেস্ট

Test-driven development (TDD) ক্রম উল্টে দেয়: কোড লেখার আগে টেস্ট। চক্রটির নাম red–green–refactor. লাল: এখনো নেই এমন আচরণের জন্য একটি ছোট টেস্ট লিখুন, চালিয়ে ব্যর্থ হতে দেখুন — এতে প্রমাণ হয় টেস্টটি সত্যিই কিছু যাচাই করে। সবুজ: টেস্ট পাস করানোর জন্য যতটুকু দরকার, শুধু ততটুকু কোড। পরিষ্কার: টেস্ট সবুজ রেখে কোড সুন্দর করুন। তারপর পরের ছোট টেস্ট। TDD সব কাজে মানানসই নয় — অজানা কিছু নিয়ে পরীক্ষামূলক কোডে আগে খেলে দেখাই ভালো। কিন্তু যেখানে নিয়ম স্পষ্ট (যেমন ছাড় বা নম্বর থেকে গ্রেড), সেখানে এটি ছোট, পরিষ্কার নকশার দিকে ঠেলে দেয়।

উদাহরণের বাইরে — property-based testing আর fuzzing

উপরের সব টেস্ট নির্দিষ্ট উদাহরণ: “এই ইনপুটে এই ফল।” Property-based testing অন্যভাবে ভাবে: এমন একটি নিয়ম লিখুন যা সব ইনপুটে সত্য, আর টুল হাজারো ইনপুট বানিয়ে নিয়মটি ভাঙার চেষ্টা করুক। যেমন: “ছাড়ের পরের দাম কখনো আসল দামের বেশি নয়”, “parse_money(format_money(x)) == x”, “sort করার পরে প্রতিটি উপাদান পরেরটির চেয়ে ছোট বা সমান।” Haskell-এর QuickCheck এই ধারণার জনক; C++-এ RapidCheck-এর মতো library আছে, আর Catch2-এর generator দিয়েও কাছাকাছি কাজ করা যায়। ভাঙার মতো ইনপুট পেলে ভালো টুল সেটিকে ছোট করে সবচেয়ে সরল উদাহরণ দেখায়।

Fuzzing পর্ব ৪৩-এ দেখেছেন: অদ্ভুত, এলোমেলো ইনপুট দিয়ে কোড চালানো, সাধারণত sanitizer-এর সাথে, যাতে crash বা UB ধরা পড়ে। Property-testing প্রশ্ন করে “ফল কি ঠিক?”, fuzzing প্রশ্ন করে “কোনো ইনপুটে কি প্রোগ্রাম ভাঙে?” parse_money-এর মতো parser দুটোরই আদর্শ লক্ষ্য।

CTest আর CI — টেস্টকে অভ্যাসে পরিণত করা

পর্ব ৪৭-এ CMake দিয়ে প্রজেক্ট build করতে শিখেছেন। CMake-এর সঙ্গী CTest সব টেস্ট-প্রোগ্রাম চালায় আর ফল সাজিয়ে দেখায়। নিয়ম একটাই: যে প্রোগ্রাম 0 ফেরত দেয় সে পাস, অন্য কিছু ফেরত দিলে ফেল — ঠিক যেমন আমাদের harness করে।

# CMakeLists.txt-এ
enable_testing()
add_executable(shop_tests tests/shop_tests.cpp)
target_link_libraries(shop_tests PRIVATE shop GTest::gtest_main)
include(GoogleTest)
gtest_discover_tests(shop_tests)   # প্রতিটি TEST আলাদা CTest টেস্ট

# টার্মিনালে
cmake -S . -B build && cmake --build build
ctest --test-dir build --output-on-failure -j 8
ctest --test-dir build -R Discount   # নাম মিলিয়ে কিছু টেস্ট

নিজের harness হলে gtest_discover_tests-এর জায়গায় শুধু add_test(NAME tiny COMMAND tiny_tests). এরপর আসে CI: GitHub Actions, GitLab CI-এর মতো সার্ভিস প্রতিটি push বা pull request-এ নতুন মেশিনে build করে ctest চালায়। টেস্ট লাল হলে পরিবর্তনটি মূল শাখায় ঢোকে না। পর্ব ৪৩-এর পরামর্শ মতো ভালো CI কয়েকটি build চালায়: warning-কে error বানিয়ে একবার, sanitizer দিয়ে একবার, আর সম্ভব হলে GCC, Clang ও MSVC তিনটিতেই।

Code coverage — কোন লাইন চলেছে, তার মানচিত্র

Code coverage জানায় টেস্ট চলার সময় কোডের কোন লাইন বা শাখা অন্তত একবার চলেছে। GCC-তে --coverage দিয়ে compile করে টেস্ট চালান, তারপর gcov (বা তার ওপর বানানো gcovr, lcov) রিপোর্ট দেয়। Clang-এ একই কাজ -fprofile-instr-generate -fcoverage-mapping, তারপর llvm-profdata আর llvm-cov.

g++ -std=c++23 --coverage -O0 shop.cpp shop_tests.cpp -o shop_tests
./shop_tests
gcov shop.cpp          # shop.cpp.gcov: প্রতিটি লাইন কতবার চলেছে
# #####: মানে লাইনটি একবারও চলেনি

৭ · ডিবাগিং — বৈজ্ঞানিক পদ্ধতি, error পড়া আর ঠিকভাবে print করা

অনেকে ডিবাগিং করেন এলোমেলো: এখানে একটু বদলাই, ওখানে একটি print দিই, আবার চালাই, “হয়তো এবার হবে।” এটি অন্ধকারে ঢিল ছোড়া। অভিজ্ঞ প্রোগ্রামাররা অন্য কাজ করেন — বিজ্ঞানের পদ্ধতি। প্রথমে বাগটি নিয়মিত ঘটানো যায় কি না দেখেন; তারপর একটি স্পষ্ট অনুমান, এমন একটি পরীক্ষা যা অনুমানটিকে মিথ্যা প্রমাণ করতে পারে, আর ফল দেখে সন্দেহের পরিসর অর্ধেক করা। একটি দোকানের রাতের রিপোর্ট দিয়ে দেখুন:

nightly_report: Floating point exception (core dumped)
ঘটে: সপ্তাহে ১–২ রাত, সব রাতে নয়
একই দিনের ডেটা আবার চালালে: আবার crash  ← নিয়মিত ঘটানো গেল

“বড় শাখার বিক্রি বেশি, যোগফল overflow করছে”
ভবিষ্যদ্বাণী: শুধু সবচেয়ে বড় শাখা দিলে crash হবে

./nightly_report --only Mirpur     # সবচেয়ে বড় শাখা
OK  ← crash নেই: অনুমান ১ ভুল
ভুল প্রমাণিত অনুমানও তথ্য — একটি সম্ভাবনা বাদ গেল

crash-এর রাতগুলোর মিল: সেদিন একটি শাখা বন্ধ ছিল (হরতাল/ছুটি)
“যে শাখায় কোনো বিক্রি নেই, সেখানে গড় হিসাবে শূন্য দিয়ে ভাগ”
./nightly_report --only Uttara     # সেদিন বন্ধ
Floating point exception  ← অনুমান ২ টিকে গেল

std::vector<int> sales{};      // ৫০ হাজার লাইনের ফাইল নয় — শুধু খালি
average(sales);              // এখানেই crash
পুরো রিপোর্ট বাদ, শুধু একটি ফাংশন, একটি ইনপুট

CHECK(!average({}).has_value());   // আগে লিখলাম: লাল
std::optional<int> average(const std::vector<int>& v) {
    if (v.empty()) return std::nullopt;
    ...                               // এখন সবুজ

Compiler error — ওপর থেকে পড়ুন, প্রথমটি আগে

সব বাগ চলার সময় আসে না; অনেক সময় compiler একসাথে চল্লিশটি error ছুড়ে দেয়। ভয় পাবেন না, আর শেষ থেকে পড়বেন না। নিয়ম: শুধু প্রথম error-টি পড়ুন, ঠিক করুন, আবার compile করুন। একটি ভুল প্রায়ই পরের অনেকগুলো “ভুয়া” error জন্ম দেয়, কারণ compiler প্রথম ভুলের পরে বাকি কোড ভুলভাবে বোঝে।

shop.cpp:4:2: error: expected ';' after struct definition
shop.cpp:9:5: error: 'Item' was not declared in this scope
shop.cpp:12:9: error: 'items' was not declared in this scope
... আরও ৩৭টি

এখানে struct-এর শেষে একটি ; নেই। সেটি দিলেই বাকি সব উধাও। Template-এর error আরও লম্বা হয় (পর্ব ২৮, ৪০) — শত লাইনের মাঝে নিজের ফাইলের নাম আর required from here লেখা লাইনটি খুঁজুন; সেখানেই আপনার ডাকা জায়গা। Concept ব্যবহার করলে বার্তা অনেক ছোট আর পরিষ্কার হয় — এটিও concept-এর একটি বড় সুবিধা।

assert, exception নাকি logging?

তিনটিই “কিছু ভুল হয়েছে” জানায়, কিন্তু তিনটি আলাদা প্রশ্নের উত্তর দেয়:

Print দিয়ে ডিবাগিং — ঠিকভাবে

Print debugging-কে অনেকে ছোট করে দেখেন, অথচ ঠিকভাবে করলে এটি খুব শক্তিশালী, বিশেষ করে যেখানে debugger চালানো কঠিন (thread, সার্ভার, contest). তিনটি নিয়ম: stderr-এ লিখুন (std::cerr বা std::println(stderr, ...)), যাতে আসল আউটপুটের সাথে না মেশে আর buffer-এ আটকে না থাকে; প্রসঙ্গ দিন — শুধু "here" নয়, কোন ফাংশন, কোন লাইন, কোন মান; আর কাজ শেষে সরিয়ে ফেলুন বা একটি debug সুইচের পেছনে রাখুন।

void trace(std::string_view msg,
           std::source_location loc = std::source_location::current()) {
    std::println(stderr, "[{}:{}] {}", loc.file_name(), loc.line(), msg);
}
// ব্যবহার:  trace(std::format("n={} sum={}", n, sum));
// আউটপুট:  [report.cpp:8] n=0 sum=0

৮ · Debugger — চলন্ত প্রোগ্রামকে থামিয়ে প্রশ্ন করা

Print দিয়ে আপনি আগে থেকে ঠিক করেন কী দেখবেন। Debugger উল্টো সুবিধা দেয়: প্রোগ্রাম যেকোনো জায়গায় থামিয়ে তখন যা খুশি দেখা — যেকোনো ভ্যারিয়েবল, কে কাকে ডেকেছে, এক লাইন করে এগোনো। Linux-এ GDB, macOS-এ LLDB, Windows-এ Visual Studio-র debugger; VS Code আর CLion ভেতরে এগুলোকেই ব্যবহার করে। মূল ধারণাগুলো সবগুলোতে এক:

Debugger-কে আপনার কোড চেনাতে -g দিয়ে compile করুন (debug info), আর অপটিমাইজেশন বন্ধ বা হালকা রাখুন (-O0 বা -Og). -O2-এ ভ্যারিয়েবল প্রায়ই <optimized out> দেখায় আর লাইনগুলো এলোমেলো লাফায়। এবার অংশ ৭-এর খালি-শাখার বাগটি GDB দিয়ে ধরা যাক। নিচের transcript সরল করা, চালানোর জন্য নয়:

5int average(const std::vector<int>& v) {6    int sum = 0;7    for (int x : v) sum += x;8    int n = static_cast<int>(v.size());9    return sum / n;10}14    std::println("{}: {}", name, average(v));21    print_section("Section C", {});9    if (v.empty()) return std::nullopt;

Crash হয়ে গেছে, debugger ছিল না — core dump

রাতে সার্ভারে crash হলে কেউ GDB নিয়ে বসে ছিল না। তখন কাজে লাগে core dump: crash-এর মুহূর্তে প্রসেসের মেমরির একটি ছবি, ফাইলে সেভ করা। Linux-এ ulimit -c unlimited দিয়ে এটি চালু করতে হয়, আর systemd-যুক্ত অনেক distribution-এ coredumpctl এগুলো জমা রাখে। পরে gdb ./report core খুলে bt লিখলেই crash-এর মুহূর্তের call stack — যেন সময় থামিয়ে ঘটনাস্থলে ফিরে যাওয়া। Windows-এ এর সমতুল্য minidump, যা Visual Studio খুলতে পারে। Build-এ -g রাখা (বা debug info আলাদা ফাইলে রেখে দেওয়া) জরুরি, নইলে stack-এ শুধু ঠিকানা দেখা যায়, নাম নয়।

Sanitizer — এক অনুচ্ছেদে মনে করিয়ে দেওয়া

পর্ব ৪৩-এ যা বিস্তারিত দেখেছেন, এখানে শুধু ডিবাগিংয়ের দৃষ্টিতে: debugger দেখায় crash কোথায় হলো, কিন্তু মেমরির ভুল প্রায়ই অনেক আগে ঘটে, crash হয় পরে অন্য জায়গায়। AddressSanitizer আর UBSan ভুলটিকে ঘটার মুহূর্তেই ধরে, তাই সব টেস্ট -fsanitize=address,undefined -g দিয়ে অন্তত একবার চালানো উচিত। Thread-এর বাগে (পর্ব ৪৫, ৪৬) আলাদা build-এ ThreadSanitizer. সন্দেহজনক crash-এ প্রথম প্রশ্ন: “sanitizer দিয়ে চালিয়েছি?”

৯ · বাগ শিকারের আরও তিন অস্ত্র — git bisect, রাবার হাঁস আর আগে ব্যর্থ টেস্ট

git bisect — কোন commit বাগটি আনল?

গত মাসের release-এ গ্রেড ঠিক আসত, আজ আসে না। মাঝে ২০০টি commit. প্রতিটি পড়ে দেখা অসম্ভব। git bisect এখানে binary search চালায়: আপনি একটি ভালো আর একটি খারাপ commit বলেন, git মাঝামাঝি একটি commit বের করে দেয়, আপনি টেস্ট চালিয়ে জানান ভালো না খারাপ, আর প্রতিবার সন্দেহের পরিসর অর্ধেক হয়। ২০০টি commit-এ মাত্র প্রায় ৮টি পরীক্ষা, ১০০০টিতে প্রায় ১০টি। ছোট একটি উদাহরণে দেখুন:

1c1  v1.4 release (good)2c2  add bKash payment3c3  receipt layout4c4  fix typo5c5  section report6c6  update README7c7  faster sort8c8  add Bangla font9c9  tidy includes10c10 refactor grade ladder11c11 new menu12c12 logging13c13 CI cache14c14 dark theme15c15 docs16c16 HEAD (bad)

আগে ব্যর্থ টেস্ট — off-by-one ধরা

বাগের রিপোর্ট এল: “৮০ নম্বর পাওয়া শিক্ষার্থী A+ পাচ্ছে না, A পাচ্ছে।” এটি একটি ক্লাসিক off-by-one: সীমানার নম্বরটি ভুল দিকে পড়েছে। ঠিক করার আগে আমরা এমন টেস্ট লিখি যা বাগটি দেখায়। নিচের প্রোগ্রামে একই টেস্ট-তালিকা পুরোনো (v1) আর ঠিক করা (v2) দুই সংস্করণে চলে — ইচ্ছা করেই v1-এর একটি টেস্ট ব্যর্থ হবে:

#include <print>
#include <string_view>

struct Case { int marks; std::string_view want; };
constexpr Case cases[]{{100, "A+"}, {80, "A+"}, {79, "A"},
                       {70, "A"}, {33, "pass"}, {32, "F"}};

std::string_view grade_v1(int m) {     // bug report: "80 shows A"
    return m > 80 ? "A+" : m >= 70 ? "A" : m >= 33 ? "pass" : "F";
}
std::string_view grade_v2(int m) {     // fixed: boundary included
    return m >= 80 ? "A+" : m >= 70 ? "A" : m >= 33 ? "pass" : "F";
}
void run(std::string_view name, auto grade) {
    int fails = 0;
    for (auto [m, want] : cases)
        if (auto got = grade(m); got != want) {
            ++fails;
            std::println("{}: FAIL marks {} got {} want {}", name, m, got, want);
        }
    std::println("{}: {} of {} failed", name, fails, std::size(cases));
}
int main() { run("v1", grade_v1); run("v2", grade_v2); }

রাবার হাঁসকে বুঝিয়ে বলুন

শুনতে হাস্যকর, কিন্তু কাজ করে: rubber duck debugging মানে টেবিলের একটি খেলনা হাঁসকে (বা যেকোনো বন্ধুকে, যাঁর প্রোগ্রামিং জানার দরকার নেই) কোডটি লাইন ধরে ধরে জোরে বুঝিয়ে বলা — “এই লাইনে n হলো ছাত্রসংখ্যা, এটা কখনো শূন্য হয় না, কারণ… ও আচ্ছা, হয়।” নামটি এসেছে Andrew Hunt আর David Thomas-এর The Pragmatic Programmer (১৯৯৯) বই থেকে। কারণটি মানসিক: মাথায় আমরা ধাপ লাফিয়ে যাই, কিন্তু মুখে বললে প্রতিটি অনুমান স্পষ্ট করতে হয়, আর ভুল অনুমানটি তখন নিজেই চোখে পড়ে। প্রশ্ন লিখতে গিয়েও একই ঘটনা ঘটে — অনেকে Stack Overflow-তে প্রশ্ন লিখতে লিখতেই উত্তর পেয়ে যান।

১০ · AI-এর যুগে — AI-এর লেখা টেস্ট আর AI দিয়ে ডিবাগিং

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

AI-এর শক্তি অন্য জায়গায়: সে এমন edge case মনে করিয়ে দিতে পারে যা আপনি ভাবেননি, আর লম্বা stack trace বা template error-কে সহজ ভাষায় ব্যাখ্যা করতে পারে। তাকে কোড লেখক নয়, প্রশ্নকর্তা হিসেবে ব্যবহার করুন:

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

• প্রতিটি প্রত্যাশিত মান আমি নিয়ম থেকে নিজে মিলিয়েছি, কোডের বর্তমান আউটপুট থেকে নয়
• খালি, এক, অনেক, সীমানা, অবৈধ আর বিশাল — ছয় ঘরের প্রতিটিতে অন্তত একটি টেস্ট আছে
• কোডে ইচ্ছা করে একটি ভুল ঢুকিয়ে দেখেছি (যেমন >= থেকে >) — অন্তত একটি টেস্ট লাল হয়
• টেস্টগুলো শুধু public আচরণ যাচাই করে; ভেতরের নকশা বদলালেও টিকে থাকবে
• কোনো টেস্ট আসল ঘড়ি, random বা নেটওয়ার্কের ওপর নির্ভর করে না; কয়েকবার ও এলোমেলো ক্রমে চালিয়েও একই ফল
• AI-এর দেওয়া crash-এর ব্যাখ্যা debugger বা sanitizer দিয়ে নিজে নিশ্চিত করেছি — অনুমানকে সত্য ধরে কোড বদলাইনি