টেস্টিং — JUnit 5 দিয়ে কোডের নিরাপত্তা জাল

১ · টেস্ট কী, আর কেন — কয়েক সেকেন্ডের নিরাপত্তা জাল

এতদিন কোড লেখার পর আপনি কী করেছেন? চালিয়েছেন, আউটপুট চোখে দেখেছেন, মনে মনে বলেছেন “ঠিক আছে”। একটি ছোট প্রোগ্রামের জন্য এটা চলে। কিন্তু ভাবুন একটি মোবাইল ওয়ালেট অ্যাপের কথা: send money, cash out, রিচার্জ, বিল পেমেন্ট — প্রতিটির চার্জের নিয়ম আলাদা, প্রতিটিতে দশ-বিশটি বিশেষ অবস্থা। আজ একজন developer cash out-এর চার্জ বদলালেন। send money কি এখনও ঠিক আছে? প্রতিবার সব কিছু হাতে চালিয়ে দেখা অসম্ভব।

এখানেই টেস্ট। টেস্ট হলো এমন কোড, যা আপনার কোডকে জানা ইনপুট দিয়ে চালায় আর ফলাফল নিজে থেকেই প্রত্যাশার সাথে মেলায়। মানুষকে আউটপুট পড়তে হয় না; মিললে পাস, না মিললে ফেল।

যে bug আগে ঠিক ছিল এমন কোডে নতুন বদলের কারণে ঢোকে, তার নাম regression. টেস্টের সবচেয়ে বড় কাজ এই regression ধরা। আর এর একটি গভীর ফল আছে — যে কোডের চারপাশে ভালো টেস্ট আছে, সেটা নির্ভয়ে বদলানো যায়। পর্ব ২২-এ বলা refactoring (আচরণ না বদলে ভেতরের গঠন উন্নত করা) টেস্ট ছাড়া জুয়া, টেস্টসহ নিয়মিত কাজ।

test pyramid — কোন টেস্ট কত

কতটুকু কোড একসাথে যাচাই হচ্ছে, তার ওপর ভিত্তি করে তিনটি স্তর ভাবা হয়। এদের সাজানো রূপকে বলে test pyramid — নিচে চওড়া, ওপরে সরু:

এই পর্বের বেশিরভাগ অংশ নিচের স্তর নিয়ে — integration test আর end-to-end test অংশ ৭-এ সংক্ষেপে আসবে। পিরামিডের যুক্তি সহজ: সস্তা আর দ্রুত টেস্ট বেশি লিখুন, দামি আর ধীর টেস্ট শুধু সেখানে, যেখানে অন্য কিছু দিয়ে কাজ হয় না। (এই আকার নিয়েও বিতর্ক আছে — ভাবনার প্রশ্ন ৩।)

২ · প্রথম টেস্ট হাতে লেখা — assertion কী জিনিস

JUnit শেখার আগে টেস্টের মূল কৌশলটা খালি হাতে দেখা যাক, যাতে framework-কে আর জাদু মনে না হয়। একটি কাল্পনিক send money চার্জের নিয়ম: ১ থেকে ৫০০ টাকায় ৫ টাকা, ৫০১ থেকে ২০০০ টাকায় ১০ টাকা, তার বেশি হলে ১%. (এগুলো শেখার জন্য বানানো হার, কোনো আসল সেবার নয়।) কোড লিখেছেন একজন, তাড়াহুড়োয়। টেস্টের কেন্দ্রে থাকে একটি assertion — “এই মান এটাই হওয়ার কথা” বলে যাচাই করা, না মিললে ফেল ঘোষণা। নিচে দুটি ছোট assertion helper আর ছয়টি test case:

class FeeCalculator {
    // কাল্পনিক slab: ১–৫০০ টাকায় ৫, ৫০১–২০০০ টাকায় ১০, তার বেশি হলে ১%
    static long fee(long amount) {
        if (amount <= 0) throw new IllegalArgumentException("amount must be positive");
        if (amount < 500) return 5;
        if (amount <= 2000) return 10;
        return amount / 100;
    }
}
class Main {
    static int run, failed;
    static void report(String name, boolean ok, String why) {
        run++; if (!ok) failed++;
        System.out.println(ok ? "PASS " + name : "FAIL " + name + " -> " + why);
    }
    static void assertEquals(long expected, long actual, String name) {
        report(name, expected == actual, "expected: <" + expected + "> but was: <" + actual + ">");
    }
    static void assertThrows(Class<? extends Exception> type, Runnable code, String name) {
        try { code.run(); report(name, false, "nothing thrown"); }
        catch (Exception e) { report(name, type.isInstance(e), "wrong exception " + e); }
    }
    public static void main(String[] args) {
        assertEquals(5, FeeCalculator.fee(1), "smallest amount");
        assertEquals(5, FeeCalculator.fee(500), "upper edge of slab 1");
        assertEquals(10, FeeCalculator.fee(501), "lower edge of slab 2");
        assertEquals(10, FeeCalculator.fee(2000), "upper edge of slab 2");
        assertEquals(25, FeeCalculator.fee(2500), "percent slab");
        assertThrows(IllegalArgumentException.class, () -> FeeCalculator.fee(0), "zero is rejected");
        System.out.println("Tests run: " + run + ", Failures: " + failed);
    }
}

প্রতিটি টেস্টের ভেতরে তিনটি অংশ থাকে, এমনকি এক লাইনের টেস্টেও: প্রস্তুতি (কোন ইনপুট), কাজ (method ডাকা), যাচাই (ফল মেলানো)। এই গঠনের নাম Arrange-Act-Assert, সংক্ষেপে AAA. একই ধারণার আরেকটি নাম Given-When-Then — “ধরা যাক ব্যালান্স ১০০০ (given), যখন ৩০০ তোলা হয় (when), তখন ব্যালান্স ৭০০ (then)”.

পর্ব ৪৫-এ আপনি @MyTest annotation আর reflection দিয়ে একটি mini test runner বানিয়েছিলেন। ওপরের helper আর সেই runner মিলালে প্রায় একটি ছোট JUnit হয়ে যায়: runner টেস্ট খোঁজে আর চালায়, helper যাচাই করে আর পরিষ্কার বার্তা দেয়।

৩ · JUnit 5-এর শুরু — @Test, assertion আর টেস্টের জীবনচক্র

JUnit JDK-র অংশ নয়; এটা একটি বাইরের library, তাই পর্ব ৪৬-এর মতো Maven বা Gradle দিয়ে যোগ করতে হয়। Maven-এ pom.xml-এ একটি dependency (সংস্করণ নম্বর উদাহরণ মাত্র; নতুন প্রজেক্টে সর্বশেষটি দেখে নিন):

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.11.0</version>
    <scope>test</scope>          <!-- শুধু টেস্টের সময় লাগবে -->
</dependency>

scope test মানে চূড়ান্ত .jar-এ JUnit যাবে না। আর কোড থাকে দুই ফোল্ডারে: আসল কোড src/main/java-এ, টেস্ট src/test/java-এ, একই package-এ। নাম JUnit Jupiter দেখে অবাক হবেন না: JUnit 5 তিন ভাগে তৈরি — Platform (টেস্ট খুঁজে চালানোর ইঞ্জিন, যা IDE আর Maven ব্যবহার করে), Jupiter (আপনি যে annotation আর assertion লেখেন), আর Vintage (পুরোনো JUnit 4-এর টেস্ট চালানোর জন্য)।

এবার একটি আসল class — পর্ব ১৭-এর ধাঁচে একটি ওয়ালেট, যার টাকা তোলার দুটি নিয়ম:

class Wallet {
    private long balance;
    private final List<String> history = new ArrayList<>();

    Wallet(long opening) { balance = opening; }

    void withdraw(long amount) {
        if (amount <= 0) throw new IllegalArgumentException("amount must be positive");
        if (amount > balance) throw new IllegalStateException("insufficient balance");
        balance -= amount;
        history.add("withdraw " + amount);
    }
    long balance() { return balance; }
    List<String> history() { return List.copyOf(history); }
}

আর তার টেস্ট class (চলবে Maven বা IDE-তে; অনলাইন runner-এ JUnit নেই):

import org.junit.jupiter.api.*;
import static org.junit.jupiter.api.Assertions.*;

@DisplayName("Wallet — টাকা তোলার নিয়ম")
class WalletTest {
    private Wallet wallet;

    @BeforeEach
    void setUp() {
        wallet = new Wallet(1000);                       // Arrange: প্রতিটি টেস্টের আগে নতুন ওয়ালেট
    }

    @Test
    @DisplayName("ব্যালান্সের মধ্যে তুললে টাকা কমে আর ইতিহাসে লেখা হয়")
    void withdraw_withinBalance_reducesBalance() {
        wallet.withdraw(300);                            // Act
        assertEquals(700, wallet.balance());             // Assert: প্রত্যাশিত মান আগে
        assertEquals(List.of("withdraw 300"), wallet.history());
    }

    @Test
    @DisplayName("ব্যালান্সের বেশি তুললে exception, ব্যালান্স অক্ষত")
    void withdraw_moreThanBalance_throwsAndKeepsBalance() {
        var e = assertThrows(IllegalStateException.class, () -> wallet.withdraw(1500));
        assertEquals("insufficient balance", e.getMessage());
        assertEquals(1000, wallet.balance());
    }

    @Test
    void newWallet_hasOpeningBalanceAndNoHistory() {
        assertAll("নতুন ওয়ালেট",
            () -> assertEquals(1000, wallet.balance()),
            () -> assertTrue(wallet.history().isEmpty()));
    }
}

কয়েকটি জিনিস লক্ষ করুন। টেস্ট class আর method-এ public লাগে না (JUnit 4-এ লাগত); শুধু private হওয়া চলবে না। কোনো main নেই — JUnit Platform reflection দিয়ে @Test-ওয়ালা method খুঁজে চালায়, ঠিক পর্ব ৪৫-এর runner-এর মতো। @DisplayName দিয়ে রিপোর্টে বাংলায় পড়ার মতো নাম দেওয়া যায়; IDE-র টেস্ট-প্যানেলে method-এর নামের বদলে এটাই দেখায়।

প্রধান assertion — কোনটা কখন

কোনো assertion ব্যর্থ হলে JUnit একটি AssertionFailedError ছোড়ে, যার বার্তা expected: <700> but was: <1000> ধরনের — অংশ ২-এর helper-এর মতোই। টেস্টের ভেতরে অপ্রত্যাশিত exception (যেমন NullPointerException) হলেও টেস্ট ব্যর্থ হয়; Maven-এর রিপোর্টে প্রথমটি গোনা হয় Failure, দ্বিতীয়টি Error হিসেবে।

জীবনচক্র — আর কেন প্রতিটি টেস্ট নতুন object পায়

lifecycle annotation বলে কোন কোড কখন চলবে। তিনটি টেস্টওয়ালা একটি class-এ JUnit এই ক্রমে চলে:

@BeforeAll  (static, পুরো class-এ একবার — যেমন ভারী কিছু তৈরি)
  নতুন WalletTest object → @BeforeEach → টেস্ট ১ → @AfterEach
  নতুন WalletTest object → @BeforeEach → টেস্ট ২ → @AfterEach
  নতুন WalletTest object → @BeforeEach → টেস্ট ৩ → @AfterEach
@AfterAll   (static, শেষে একবার — যেমন পরিষ্কার করা)

সবচেয়ে গুরুত্বপূর্ণ লাইনটি “নতুন WalletTest object”. JUnit 5 ডিফল্টে প্রতিটি টেস্ট method-এর জন্য টেস্ট class-এর নতুন instance বানায়। তাই এক টেস্টে wallet.withdraw(300) করলেও পরের টেস্ট আবার ১০০০ টাকার নতুন ওয়ালেট পায়। একে বলে টেস্টের স্বাধীনতা: প্রতিটি টেস্ট একা চললেও পাস করবে, যেকোনো ক্রমে চললেও। এ কারণেই @BeforeAll method static হতে হয় — তখনো কোনো instance থাকে না। (@TestInstance(Lifecycle.PER_CLASS) দিয়ে এই আচরণ বদলানো যায়, তবে তখন অবস্থা ভাগ হওয়ার ঝুঁকি আপনার।) টেস্টের ক্রমও JUnit নিশ্চিত করে না।

নামের রীতি আর একটি টেস্টে একটি আচরণ

টেস্ট ফেল করলে প্রথমে চোখে পড়ে তার নাম। test1 কিছুই বলে না; withdraw_moreThanBalance_throwsAndKeepsBalance পড়েই বোঝা যায় কোন নিয়ম ভেঙেছে। প্রচলিত দুটি রীতি:

• methodName_condition_expected: fee_amountIs500_returnsFive — কোন method, কোন অবস্থায়, কী প্রত্যাশা।
• should… বা বাক্যের মতো: shouldRejectZeroAmount(), সাথে @DisplayName("শূন্য টাকা গ্রহণ করে না").

দলে যেটা চলে সেটাই মানুন। আর একটি টেস্ট একটি আচরণ যাচাই করবে — তিনটি নিয়ম এক টেস্টে থাকলে প্রথমটি ফেল করলেই বাকিগুলোর খবর হারায়। (একই আচরণের কয়েকটি দিক — যেমন ব্যালান্স আর ইতিহাস — একসাথে যাচাই করা ঠিক আছে; সেখানে assertAll কাজে লাগে।)

৪ · parameterized test — একটি টেবিল, অনেক টেস্ট

অংশ ২-এ চার্জের পাঁচটি মান যাচাই করতে পাঁচটি প্রায় একই লাইন লিখতে হয়েছিল। VAT-এর হার, চার্জের slab, পরীক্ষার গ্রেড — এমন নিয়ম আসলে একটি টেবিল। JUnit-এ টেবিলটা সরাসরি লেখা যায়, আর প্রতিটি সারি একটি আলাদা টেস্ট হয়ে চলে। এর নাম parameterized test:

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.*;
import static org.junit.jupiter.api.Assertions.*;

class FeeCalculatorTest {
    @ParameterizedTest(name = "[{index}] {0} টাকা → চার্জ {1}")
    @CsvSource({
        "1,    5",
        "500,  5",
        "501,  10",
        "2000, 10",
        "2500, 25"
    })
    void fee_followsSlabTable(long amount, long expectedFee) {
        assertEquals(expectedFee, FeeCalculator.fee(amount));
    }

    @ParameterizedTest
    @ValueSource(longs = {0, -1, -500})
    void fee_nonPositiveAmount_isRejected(long amount) {
        assertThrows(IllegalArgumentException.class, () -> FeeCalculator.fee(amount));
    }
}

@CsvSource-এর প্রতিটি String একটি সারি; কমা দিয়ে ভাগ করা মানগুলো method-এর parameter-এ যায়, আর JUnit নিজেই String থেকে long-এ রূপান্তর করে। @ValueSource এক parameter-এর টেস্টের জন্য — একটি মানের তালিকা। এই দুই annotation-এর জন্য junit-jupiter-params লাগে, যা ওপরের junit-jupiter dependency-র সাথেই আসে। একটি টেবিল কীভাবে আলাদা আলাদা টেস্ট হয়, ধাপে ধাপে দেখুন (অংশ ২-এর সেই < 500 bug এখনও কোডে আছে ধরে নিয়ে):

1@ParameterizedTest(name = "[{index}] {0} টাকা → চার্জ {1}")2@CsvSource({3    "1,    5",4    "500,  5",5    "501,  10",6    "2000, 10",7    "2500, 25" })8void fee_followsSlabTable(long amount, long expectedFee) {9    assertEquals(expectedFee, FeeCalculator.fee(amount)); }

@Nested আর @Disabled — টেস্ট সাজানো

class WalletTest {
    @Nested
    @DisplayName("ব্যালান্স শূন্য হলে")
    class WhenEmpty {
        Wallet wallet = new Wallet(0);

        @Test void anyWithdraw_throws() {
            assertThrows(IllegalStateException.class, () -> wallet.withdraw(1));
        }
    }

    @Test
    @Disabled("দৈনিক সীমা এখনও তৈরি হয়নি — টিকিট #142")
    void withdraw_overDailyLimit_throws() { }
}

@Nested দিয়ে একটি অবস্থার সব টেস্ট একটি inner class-এ রাখা যায় (পর্ব ২৭-এর inner class — static নয়); রিপোর্টে গাছের মতো দেখায়: “Wallet → ব্যালান্স শূন্য হলে → anyWithdraw_throws”. @Disabled টেস্টকে সাময়িক বাদ রাখে, রিপোর্টে “Skipped” হিসেবে গোনা হয়। সবসময় কারণ লিখুন।

টেস্ট চালানো — IDE আর Maven

IDE-তে টেস্টের পাশের সবুজ ▶ চাপলেই সেটি চলে। কমান্ড লাইনে বা CI সার্ভারে Maven:

mvn test                              # সব টেস্ট
mvn test -Dtest=FeeCalculatorTest     # শুধু একটি class
./gradlew test                        # Gradle হলে (build.gradle-এ useJUnitPlatform() লাগে)

Maven-এ টেস্ট চালায় Surefire plugin. ডিফল্টে সে src/test/java-এর এমন class খোঁজে, যার নাম Test দিয়ে শুরু বা Test, Tests বা TestCase দিয়ে শেষ — তাই WalletChecks নামের class নীরবে বাদ পড়বে। ওপরের ফি-টেস্ট (bug-সহ) চালালে রিপোর্টের মূল অংশ এমন দেখায়:

প্রত্যাশিত আউটপুট (সংক্ষেপে) — সময়, লাইন নম্বর আর বাড়তি লাইন বাদ দেওয়া; সংস্করণভেদে খুঁটিনাটি আলাদা হয়:

[INFO]  T E S T S
[INFO] Running FeeCalculatorTest
[ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 0 ... <<< FAILURE!
...
[ERROR] Failures:
[ERROR]   FeeCalculatorTest.fee_followsSlabTable ... expected: <5> but was: <10>
[ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 0
[INFO] BUILD FAILURE

৮টি টেস্ট কেন? টেবিলের ৫টি সারি আর @ValueSource-এর ৩টি মান — প্রতিটি আলাদা টেস্ট। Skipped গোনে @Disabled টেস্ট। আর শেষের BUILD FAILURE গুরুত্বপূর্ণ: একটি টেস্ট ফেল করলে mvn package-ও থেমে যায়, ফলে ভাঙা কোড .jar হয়ে সার্ভারে যেতে পারে না। দলগুলো প্রতিটি push-এ এই কাজ স্বয়ংক্রিয়ভাবে চালায় — একে বলে continuous integration (CI).

৫ · exception আর edge case — যেখানে bug লুকিয়ে থাকে

নতুনদের লেখা টেস্টে সবচেয়ে বড় ফাঁক: শুধু happy path — সব ঠিকঠাক চলার পথ। ১০০০ টাকার ওয়ালেট থেকে ৩০০ তোলা, পাস, শেষ। কিন্তু bug থাকে কিনারায়। পর্ব ০২-এ দেখা edge case-এর ধারণা এখানে একটি পদ্ধতি হয়ে যায়।

প্রথম ধাপ: ইনপুটকে এমন দলে ভাগ করুন, যাদের ভেতরে কোডের আচরণ একই — একে বলে equivalence partitioning. withdraw-এর জন্য: অবৈধ (০ বা কম), বৈধ (১ থেকে ব্যালান্স), বেশি (ব্যালান্সের ওপরে)। প্রতিটি দল থেকে অন্তত একটি মান। দ্বিতীয় ধাপ: দলের সীমায় দুই পাশের মান নিন — কারণ প্রোগ্রামাররা ভুল করেন ঠিক সেখানে, < আর <=-এর মধ্যে (পর্ব ১১-এর off-by-one). এর নাম boundary value analysis. ব্যালান্স ১০০০ হলে:

অন্য টাইপের জন্য একই চিন্তা: String হলে null, "", শুধু space, খুব লম্বা, বাংলা অক্ষর (পর্ব ০৮-এর UTF-16); collection হলে খালি, একটি উপাদান, ডুপ্লিকেট; তারিখ হলে মাসের শেষ দিন, ২৯ ফেব্রুয়ারি, মধ্যরাত (পর্ব ৩৮)।

exception টেস্ট করার সময় তিনটি জিনিস যাচাই করুন: সঠিক টাইপ (assertThrows), দরকার হলে বার্তা (ফেরত পাওয়া exception থেকে), আর অবস্থা অক্ষত — exception-এর পরেও ব্যালান্স বদলায়নি তো? তৃতীয়টি সবচেয়ে বেশি বাদ পড়ে। পর্ব ১৬-এ বলা fail-fast নীতি — অবস্থা বদলানোর আগেই সব যাচাই — এই ঝুঁকি কমায়, আর টেস্ট নিশ্চিত করে নীতিটা মানা হচ্ছে।

AssertJ — পড়তে সহজ assertion

অনেক দল JUnit-এর সাথে AssertJ library ব্যবহার করে। এর assertion বাক্যের মতো পড়া যায়, আর ফেলের বার্তা আরও বিস্তারিত:

import static org.assertj.core.api.Assertions.*;

assertThat(wallet.balance()).isEqualTo(700);
assertThat(wallet.history()).hasSize(1).containsExactly("withdraw 300");
assertThatThrownBy(() -> wallet.withdraw(1500))
    .isInstanceOf(IllegalStateException.class)
    .hasMessage("insufficient balance");

প্রতিটি assertion assertThat(actual) দিয়ে শুরু হয়, তাই expected-actual উল্টে যাওয়ার ভয় নেই।

৬ · test double — আসল SMS না পাঠিয়ে টেস্ট

একটি OrderService অর্ডার নিলে গ্রাহককে SMS পাঠায়। টেস্ট চালালে কি সত্যিই SMS যাবে? প্রতিবার টাকা খরচ, নেটওয়ার্ক না থাকলে টেস্ট ফেল, আর কোন SMS গেল তা যাচাই করার উপায় নেই। সমাধান: পর্ব ২১-এর মতো SMS পাঠানোকে একটি interface-এর পেছনে রাখা — interface SmsSender { void send(String phone, String text); } — আর টেস্টে আসল gateway-এর বদলে একটি নকল বসানো। টেস্টে আসল নির্ভরতার জায়গায় যে বসে, তার নাম test double. Gerard Meszaros তাঁর xUnit Test Patterns বইয়ে এর পাঁচটি ধরন আলাদা করেছেন, আর Martin Fowler-এর পরিচিত প্রবন্ধ “Mocks Aren't Stubs” নামগুলো জনপ্রিয় করেছে। একই SmsSender-এর ওপর চারটি দেখুন:

SmsSender dummy = (phone, text) -> {
    throw new AssertionError("should not be called");
};
// টেস্টটা শুধু invalid অর্ডার বাতিল হয় কি না দেখছে —
// SMS এই পথে কখনো পৌঁছায় না
assertThrows(IllegalArgumentException.class,
    () -> new OrderService(dummy, clock).place("017...", 0));

interface VatRates { int percentFor(String category); }

VatRates stub = category -> 15;        // সবসময় ১৫%
var calc = new InvoiceCalculator(stub);
assertEquals(1150, calc.total(1000, "electronics"));
// stub কোডকে ইনপুট দেয়; কে কতবার ডাকল তা দেখে না

class FakeSmsSender implements SmsSender {
    final List<String> sent = new ArrayList<>();
    public void send(String p, String t) { sent.add(p + " | " + t); }
}
// নেটওয়ার্কের বদলে একটি List. পরে টেস্ট দেখে কী জমা হলো:
assertEquals(1, fake.sent.size());
// in-memory ডেটাবেস বা Map-ভিত্তিক repository-ও fake

SmsSender sms = mock(SmsSender.class);
new OrderService(sms, clock).place("01712345678", 1500);

verify(sms).send(eq("01712345678"), contains("1500 Tk"));
verify(sms, times(1)).send(anyString(), anyString());
// mock ডাকগুলো রেকর্ড করে; verify প্রত্যাশা না মিললে ফেল

dummy  → লাগে, কিন্তু ব্যবহার হয় না
stub   → কোডকে ইনপুট জোগাতে (হার, কনফিগ, আজকের তারিখ)
fake   → সরল আসল আচরণ দরকার, পরে অবস্থা দেখবেন
mock   → ডাকটাই ফল (SMS গেল কি না, কতবার)
spy    → আসল object, কিন্তু ডাকগুলো রেকর্ড হয়

Mockito-র মূল তিনটি কাজ

Mockito Java-র সবচেয়ে প্রচলিত mocking library (এটাও Maven dependency, অনলাইনে চালানো যাবে না)। মূল কাজ তিনটি — নকল বানানো, উত্তর ঠিক করা, ডাক যাচাই করা:

import static org.mockito.Mockito.*;

@Test
void total_usesRateFromRepository_andSendsSms() {
    VatRates rates = mock(VatRates.class);                 // ১. নকল বানানো
    SmsSender sms = mock(SmsSender.class);
    when(rates.percentFor("electronics")).thenReturn(15);   // ২. উত্তর ঠিক করা (stub-এর মতো)

    var service = new InvoiceService(rates, sms);
    long total = service.bill("01712345678", 1000, "electronics");

    assertEquals(1150, total);
    verify(sms).send("01712345678", "Total 1150 Tk");       // ৩. ডাক যাচাই
    verify(sms, never()).send(eq("01812345678"), anyString());
}

@ExtendWith(MockitoExtension.class) দিলে field-এ @Mock লিখেও নকল বানানো যায়।

হাতে লেখা fake আর নির্দিষ্ট ঘড়ি — চালিয়ে দেখুন

এখানে Mockito ছাড়া, শুধু JDK দিয়ে পুরো ব্যাপারটা। OrderService-এর দুটি নির্ভরতা — SMS আর সময় — দুটোই constructor দিয়ে আসে। নিয়ম: অর্ডার নিলে SMS-এ ডেলিভারির তারিখ জানানো হয়; সাধারণত দুই দিন পরে, কিন্তু রাত ৮টার পরে অর্ডার হলে তিন দিন। টেস্টে পর্ব ৩৮-এর Clock.fixed দিয়ে সময় বেঁধে দেওয়া হয়েছে:

import java.time.*;
import java.util.*;
interface SmsSender { void send(String phone, String text); }
class FakeSmsSender implements SmsSender {             // হাতে লেখা fake
    final List<String> sent = new ArrayList<>();
    public void send(String phone, String text) { sent.add(phone + " | " + text); }
}
class OrderService {
    private final SmsSender sms; private final Clock clock;
    OrderService(SmsSender sms, Clock clock) { this.sms = sms; this.clock = clock; }
    void place(String phone, long amount) {
        if (amount <= 0) throw new IllegalArgumentException("amount must be positive");
        LocalDateTime now = LocalDateTime.now(clock);
        int days = now.getHour() >= 20 ? 3 : 2;             // রাত ৮টার পরে হলে এক দিন বেশি
        sms.send(phone, "Order " + amount + " Tk confirmed, delivery by " + now.toLocalDate().plusDays(days));
    }
}
class Main {
    static Clock at(String t) { var z = ZoneId.of("Asia/Dhaka"); return Clock.fixed(LocalDateTime.parse(t).atZone(z).toInstant(), z); }
    public static void main(String[] args) {
        var fake = new FakeSmsSender();
        new OrderService(fake, at("2026-10-18T10:00")).place("01712345678", 1500);
        new OrderService(fake, at("2026-10-18T21:30")).place("01812345678", 700);
        try { new OrderService(fake, at("2026-10-18T10:00")).place("01912345678", 0); }
        catch (IllegalArgumentException e) { System.out.println("rejected: " + e.getMessage()); }
        fake.sent.forEach(System.out::println);
        System.out.println(fake.sent.size() == 2 ? "PASS 2 sms, none for the bad order" : "FAIL");
    }
}

কখন হাতে লেখা fake ভালো

• fake ভালো যখন: একই নির্ভরতা অনেক টেস্টে লাগে — ৩০ বার when(...) লেখার চেয়ে একটি FakeSmsSender সহজ; আর ফল দেখে যাচাই করায় refactoring-এ টেস্ট কম ভাঙে।
• mock ভালো যখন: নির্দিষ্ট ডাকটাই ব্যবসার নিয়ম (“ব্যর্থ পেমেন্টে কখনো SMS যাবে না”), বা exception-এর অবস্থা তৈরি করা দরকার (when(...).thenThrow(...))।
• নিয়ম: শুধু ধীর বা অনিয়ন্ত্রিত বাইরের জিনিস (নেটওয়ার্ক, ঘড়ি, এলোমেলো সংখ্যা) নকল করুন; নিজের record বা সরল class-এর (পর্ব ২৫) mock প্রায় সবসময় অপ্রয়োজনীয়।

৭ · টেস্টযোগ্য নকশা আর flaky টেস্ট

কিছু কোড টেস্ট করা সহজ, কিছু প্রায় অসম্ভব। পার্থক্যটা সাধারণত টেস্টে নয়, কোডের নকশায়। এই কোডটি দেখুন:

class OrderService {                                      // টেস্ট করা কঠিন
    void place(String phone, long amount) {
        var sms = new BkashSmsGateway("api-key-123");        // নিজেই বানায় — বদলানো যায় না
        LocalDateTime now = LocalDateTime.now();             // আসল ঘড়ি — নিয়ন্ত্রণ নেই
        double vat = AppConfig.VAT_RATE;                      // static, যে কেউ বদলাতে পারে
        sms.send(phone, "...");
    }
}

এর টেস্ট লিখতে গেলে প্রতিবার আসল SMS যাবে, ফল নির্ভর করবে কখন চালাচ্ছেন তার ওপর, আর এক টেস্টে AppConfig.VAT_RATE বদলালে পরের টেস্ট সেই বদল দেখবে। অংশ ৬-এর সংস্করণে তিনটি সমস্যারই সমাধান একই নীতি:

• নির্ভরতা বাইরে থেকে, constructor দিয়ে: পর্ব ২১-এর dependency injection. class নিজে new BkashSmsGateway() করে না; কেউ তাকে একটি SmsSender দেয়। আসল অ্যাপে আসল gateway, টেস্টে fake. এর ভিত্তি program to an interface — parameter-এর টাইপ interface, নির্দিষ্ট class নয়। পর্ব ৫০-এ Spring এই জোড়া লাগানোর কাজটা নিজে করবে।
• সময়ও একটি নির্ভরতা: LocalDateTime.now()-এর বদলে LocalDateTime.now(clock), আর Clock constructor-এ। এলোমেলো সংখ্যার ক্ষেত্রেও একই: new Random()-এর বদলে বাইরে থেকে দেওয়া Random বা RandomGenerator, যাতে টেস্টে নির্দিষ্ট seed দেওয়া যায়।
• বদলানো যায় এমন static এড়ানো: পর্ব ১৮-এর global state টেস্টের শত্রু, কারণ টেস্টগুলো একে অপরের অবস্থা দেখে ফেলে। হার, কনফিগ — এগুলোও constructor দিয়ে দিন। static final ধ্রুবক (যা কখনো বদলায় না) সমস্যা নয়।

যে নকশা টেস্ট সহজ করে, সেটাই নমনীয় নকশা; টেস্ট লিখতে কষ্ট হওয়া প্রায়ই নকশার সমস্যার প্রথম সংকেত। একে বলে testability, আর পরের পর্বের design pattern-গুলোর অনেকগুলোর পেছনে এই একই চিন্তা।

flaky টেস্ট — কখনো পাস, কখনো ফেল

কোড না বদলেও যে টেস্ট কখনো পাস আর কখনো ফেল করে, তাকে বলে flaky test. কয়েকবার “আবার চালাও, ঠিক হয়ে যাবে” করার পর দল টেস্টের লাল রং বিশ্বাস করা বন্ধ করে দেয় — তখন আসল bug-ও উপেক্ষিত হয়। প্রধান কারণ আর সমাধান:

integration test — অংশগুলো জোড়া লাগে তো?

unit test প্রমাণ করে প্রতিটি অংশ আলাদাভাবে ঠিক। কিন্তু আপনার SQL কি আসল ডেটাবেসে চলে? JSON-এর field-এর নাম কি অন্য সার্ভিসের সাথে মেলে? এগুলো ধরা পড়ে integration test-এ। জনপ্রিয় একটি পদ্ধতি Testcontainers library: টেস্টের শুরুতে Docker দিয়ে একটি আসল PostgreSQL বা MySQL চালু করে, টেস্ট শেষে মুছে ফেলে — প্রতিবার পরিষ্কার, আসল ডেটাবেস। পর্ব ৪৯-এ JDBC-র সাথে এর ব্যবহার আরও অর্থবহ হবে।

৮ · TDD — আগে টেস্ট, তারপর কোড; আর coverage-এর সীমা

এতক্ষণ কোড লিখে পরে টেস্ট লিখেছি। test-driven development (TDD) উল্টো দিক থেকে কাজ করে: আগে একটি ব্যর্থ টেস্ট, তারপর সেটা পাস করানোর মতো ন্যূনতম কোড, তারপর পরিষ্কার করা। এই চক্রের নাম red-green-refactor — IDE-তে ফেল করা টেস্ট লাল, পাস করা সবুজ দেখায়। একটি sign-up form-এর password-শক্তি যাচাইয়ের উদাহরণে তিন পাক ঘুরে দেখুন:

@Test void shortPassword_isWeak() {
    assertEquals(WEAK, PasswordChecker.check("ab12"));
}
compile error: PasswordChecker নেই  ← এটাও “লাল”

static Strength check(String p) {
    return p.length() < 8 ? WEAK : STRONG;
}
টেস্ট ১ ✔  — digit-এর নিয়ম এখনও নেই, ইচ্ছা করেই

@Test void noDigit_isWeak() {
    assertEquals(WEAK, PasswordChecker.check("abcdefgh"));
}
✘ expected: <WEAK> but was: <STRONG>
টেস্ট ১ ✔  টেস্ট ২ ✘

if (p.length() < 8) return WEAK;
if (p.chars().noneMatch(Character::isDigit)) return WEAK;
return STRONG;
টেস্ট ১ ✔  টেস্ট ২ ✔

@Test void commonPassword_isWeak() {
    assertEquals(WEAK, PasswordChecker.check("Password123"));
}
✘ expected: <WEAK> but was: <STRONG>  ৮+ অক্ষর, digit আছে

static final Set<String> COMMON = Set.of("password123", "12345678", "bangladesh1");
if (p.length() < 8) return WEAK;
if (p.chars().noneMatch(Character::isDigit)) return WEAK;
if (COMMON.contains(p.toLowerCase())) return WEAK;
return STRONG;                          ✔ ✔ ✔

static final List<Predicate<String>> WEAK_RULES = List.of(
    p -> p.length() < 8,
    p -> p.chars().noneMatch(Character::isDigit),
    p -> COMMON.contains(p.toLowerCase()));

static Strength check(String p) {
    return WEAK_RULES.stream().anyMatch(r -> r.test(p)) ? WEAK : STRONG;
}
তিনটি টেস্ট আবার চালানো: ✔ ✔ ✔ — কিছু ভাঙেনি

নিয়ম স্পষ্ট এমন যুক্তিতে (চার্জ, যাচাই, পার্সার) TDD দারুণ; UI-র চেহারা নিয়ে পরীক্ষায় কম। যাঁরা সব সময় TDD করেন না, তাঁরাও bug ঠিক করার সময় একটি নিয়ম মানেন: আগে bug-টা ধরে এমন একটি ব্যর্থ টেস্ট, তারপর সমাধান। তাহলে bug আর কখনো নীরবে ফিরতে পারে না।

code coverage — কতটুকু কোড টেস্টে চলেছে

code coverage মাপে টেস্ট চলার সময় কোডের কত শতাংশ লাইন (line coverage) বা কত শতাংশ শাখা — if-এর দুই দিক (branch coverage) — অন্তত একবার চলেছে। Java-তে প্রচলিত টুল JaCoCo, যা কোন লাইন চলেছে আর কোনটা চলেনি তার রঙিন HTML রিপোর্ট দেয়।

কিন্তু উল্টোটা সত্য নয়। এই টেস্টটা দেখুন:

@Test
void fee_runs() {
    for (long a : new long[] {1, 500, 501, 2000, 2500}) FeeCalculator.fee(a);
    assertThrows(IllegalArgumentException.class, () -> FeeCalculator.fee(0));
}

এটা fee-এর প্রতিটি লাইন আর প্রতিটি শাখা চালায় — coverage ১০০%. অথচ ৫০০ টাকার < 500 bug ধরে না, কারণ ফলটা কেউ যাচাই করে না। coverage বলে কোন কোড চলেছে, কোনটা যাচাই হয়েছে তা বলে না। সুস্থ ব্যবহার: কম coverage-কে সতর্কসংকেত ধরা, বেশিকে প্রমাণ নয়। টেস্টের মান মাপার শক্তিশালী উপায় mutation testing — ভাবনার প্রশ্ন ৪-এ।

৯ · AI-এর যুগে — AI-এর লেখা টেস্ট কি আসলে কিছু যাচাই করে?

“এই class-এর জন্য unit test লিখে দাও” — AI টুলের সবচেয়ে জনপ্রিয় কাজগুলোর একটি, আর ফলাফল দেখতে চমৎকার: অনেক টেস্ট, সুন্দর নাম, সবগুলো সবুজ। সমস্যা ঠিক এখানে। AI সাধারণত দেখে আপনার কোড কী করে, তারপর সেটাই যাচাই করে — কোড কী করা উচিত তা সে জানে না। অংশ ২-এর ফি-ক্যালকুলেটর দিলে AI খুব সম্ভবত লিখবে assertEquals(10, fee(500)), কারণ কোড সেটাই দেয়। bug তখন টেস্টের ভেতরে পাকাপাকি বসে গেল। এমন টেস্টকে বলে tautological test — implementation-এর আয়না, যা কখনো ফেল করতে পারে না।

AI-এর সবচেয়ে ভালো ব্যবহার উল্টো দিকে: নিয়মটা বলে তাকে edge case প্রস্তাব করতে বলা — সে প্রায়ই এমন কিছু মনে করিয়ে দেয় যা আপনি ভাবেননি। তারপর প্রতিটির প্রত্যাশিত ফল আপনি নিজে নিয়ম থেকে ঠিক করবেন। আর একটি সহজ পরীক্ষা: AI-এর লেখা টেস্ট পেলে কোডে ইচ্ছা করে একটি ছোট bug ঢোকান (<=-কে <). কোনো টেস্ট লাল না হলে সেগুলো আপনাকে রক্ষা করছে না।

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

• প্রতিটি প্রত্যাশিত মান আমি নিয়ম থেকে নিজে মিলিয়েছি — কোডের আউটপুট দেখে নয়
• প্রতিটি টেস্টে অন্তত একটি অর্থপূর্ণ assertion আছে (শুধু assertNotNull বা কিছুই না — এমন নয়)
• ০, ঋণাত্মক, null/খালি আর প্রতিটি সীমার দুই পাশের মান আছে
• exception টেস্টে টাইপ, দরকার হলে message, আর অবস্থা অক্ষত — তিনটিই যাচাই হয়েছে
• mock শুধু বাইরের নির্ভরতার; নিজের সরল class আর record আসল
• now(), sleep, seed ছাড়া Random, ক্রমের ওপর নির্ভরতা নেই
• কোডে ইচ্ছা করে একটি ছোট bug ঢুকিয়ে দেখেছি — অন্তত একটি টেস্ট লাল হয়েছে