تست: JUnit 5، Mockito، AssertJ و TestcontainersTesting: JUnit 5, Mockito, AssertJ, Testcontainers

Let's be honest up front: many of us treat testing like a tax — something we pay so nobody complains. We write the code, then bolt on a few assertEquals calls to push "coverage" up, and move on. Six months later a bug detonates in production in code that had 90% coverage. How? Because having tests and having good tests are two completely different things.

This chapter is here to change how you see it. A test suite is your safety net — the thing that lets you make a big refactor at 5pm on a Friday and go home calmly, because if something breaks, a red light tells you before the customer does. We start from zero — what the test pyramid is, why speed matters — and build up to the modern Java tooling: JUnit 5 to run tests, Mockito to isolate units, AssertJ for readable assertions, and Testcontainers to test against a real database and Kafka inside Docker.

Why automated tests at all?

Start with a picture. You're the chef of a restaurant. Every time you add a new dish to the menu, you need to be sure the kitchen still works: the stove lights, the fridge is cold, and the old dishes still come out right. If you had to verify all of that by hand every time, you'd go mad — and still miss something.

Automated tests are a tireless assistant who, before you open the doors each day, checks all of that in a few seconds and says "everything's in place" or "hold on, sauce #3 is off." In software, this assistant lets you change things without fear. Without tests, every change is a gamble.

The test pyramid: not all tests are equal

Now the important question: what kind of test, and how many of each? This is where the Test Pyramid (popularized by Mike Cohn) comes in. It has three tiers:

• Bottom (wide): unit tests. They test one class or method in isolation from the rest of the world. Very fast (milliseconds), no database, no network. The majority of your tests belong here.
• Middle: integration tests. Several pieces working together — e.g. your code against a real database. Slower (tens/hundreds of ms), fewer of them.
• Top (narrow): end-to-end tests. The whole system from the user's point of view. Very slow and brittle, so keep them few and only for critical paths.

Why a pyramid shape? Because unit tests are cheap, fast, and precise: when they break, you know exactly where to look. End-to-end tests are expensive, slow, and vague: when they go red, anything could be broken.

JUnit 5: the test-running engine

JUnit is the de-facto standard for running tests in Java. Version 5 (released in 2017) was a complete rewrite, and despite the name, it isn't "one library" — it's built from three parts:

Your first test

Let's test a simple class:

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public int divide(int a, int b) {
        if (b == 0) {
            throw new IllegalArgumentException("division by zero");
        }
        return a / b;
    }
}

And its test with JUnit Jupiter:

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.DisplayName;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

class CalculatorTest {

    private final Calculator calc = new Calculator();

    @Test
    @DisplayName("2 plus 3 should be 5")
    void addsTwoNumbers() {
        int result = calc.add(2, 3);
        assertEquals(5, result);
    }

    @Test
    void throwsOnDivideByZero() {
        assertThrows(IllegalArgumentException.class, () -> calc.divide(10, 0));
    }
}

A few notes: test methods don't need to be public (in JUnit 5 even package-private is fine), @Test comes from org.junit.jupiter.api (not the old org.junit), and @DisplayName lets you write the test name in plain human language for readable reports.

Lifecycle: before and after each test

Often you need to set something up before each test and clean up after. JUnit 5 gives you four hooks:

import org.junit.jupiter.api.*;

class LifecycleTest {

    @BeforeAll
    static void initAll() {
        // once before all tests in this class (must be static)
        System.out.println("expensive one-time setup, e.g. opening a connection");
    }

    @BeforeEach
    void init() {
        // runs before each individual test — build fresh state here
        System.out.println("fresh setup for this test");
    }

    @Test
    void testOne() { /* ... */ }

    @Test
    void testTwo() { /* ... */ }

    @AfterEach
    void tearDown() {
        // after each test — release that test's resources
    }

    @AfterAll
    static void tearDownAll() {
        // once after all
    }
}

If you really want one shared instance for the whole class (e.g. expensive setup), you can switch to @TestInstance(TestInstance.Lifecycle.PER_CLASS), after which @BeforeAll no longer needs to be static. Use this cautiously, since it opens the door to state leakage.

Commonly used annotations

• @Disabled("reason") — temporarily disables a test (instead of commenting it out or deleting it).
• @Tag("slow") — labels a test so you can filter and run groups separately.
• @Nested — nested test classes to group scenarios (we'll see this below).
• @RepeatedTest(10) — runs a test ten times (great for hunting flaky tests).
• @Timeout(2) — fails the test if it runs longer than 2 seconds.

Assertions: how we say what "correct" means

The heart of every test is an assertion: a statement that says "I expect this to be so." If it doesn't hold, the test fails. JUnit has a base set in the Assertions class:

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

@Test
void coreAssertions() {
    assertEquals(4, 2 + 2);                       // equality
    assertNotEquals(5, 2 + 2);
    assertTrue(3 > 2, "three should be greater than two"); // optional message
    assertNull(null);
    assertNotNull("hello");
    assertSame(Boolean.TRUE, Boolean.TRUE);        // same object (==)
    assertArrayEquals(new int[]{1, 2}, new int[]{1, 2});
}

assertThrows: testing errors

One of the most important things is to confirm the code throws the right error in bad conditions:

@Test
void divideByZeroThrows() {
    IllegalArgumentException ex = assertThrows(
        IllegalArgumentException.class,
        () -> calc.divide(10, 0)
    );
    assertEquals("division by zero", ex.getMessage());
}

assertThrows returns the thrown exception so you can also assert on its message or fields.

assertAll: don't let the first failure hide the rest

The problem with plain assertions is that on the first failure, the test stops and you don't see the rest. assertAll runs all assertions and reports all failures together:

@Test
void personHasRightFields() {
    Person p = new Person("Ali", 30, "Tehran");
    assertAll("person",
        () -> assertEquals("Ali", p.name()),
        () -> assertEquals(30, p.age()),
        () -> assertEquals("Tehran", p.city())
    );
}

Parameterized tests: one test, many inputs

Often you want to exercise the same logic with different inputs. Copy-pasting a test per input is silly. @ParameterizedTest solves it:

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;
import org.junit.jupiter.params.provider.CsvSource;
import org.junit.jupiter.params.provider.MethodSource;
import java.util.stream.Stream;
import org.junit.jupiter.params.provider.Arguments;
import static org.junit.jupiter.params.provider.Arguments.arguments;

class ParameterizedExamples {

    @ParameterizedTest
    @ValueSource(ints = {2, 4, 6, 100})
    void allEven(int number) {
        assertTrue(number % 2 == 0);
    }

    @ParameterizedTest
    @CsvSource({
        "2, 3, 5",
        "0, 0, 0",
        "-1, 1, 0"
    })
    void addsCorrectly(int a, int b, int expected) {
        assertEquals(expected, new Calculator().add(a, b));
    }

    @ParameterizedTest
    @MethodSource("provideStrings")
    void checksLength(String input, int expectedLength) {
        assertEquals(expectedLength, input.length());
    }

    static Stream<Arguments> provideStrings() {
        return Stream.of(
            arguments("hi", 2),
            arguments("hello", 5)
        );
    }
}

There are more sources: @EnumSource to iterate an enum's values, @NullSource and @EmptySource for boundaries, and @CsvFileSource to read from a file. Parameterized tests both shorten the code and tempt you to cover more edge cases.

Nested tests with @Nested

When a class behaves differently under different conditions, @Nested lets you organize scenarios like folders:

class BankAccountTest {

    BankAccount account;

    @BeforeEach
    void setUp() { account = new BankAccount(100); }

    @Nested
    @DisplayName("when balance is sufficient")
    class WhenSufficientBalance {

        @Test
        void withdrawSucceeds() {
            account.withdraw(50);
            assertEquals(50, account.balance());
        }
    }

    @Nested
    @DisplayName("when balance is insufficient")
    class WhenInsufficientBalance {

        @Test
        void withdrawThrows() {
            assertThrows(InsufficientFundsException.class,
                () -> account.withdraw(200));
        }
    }
}

The IDE renders the output as a tree, which makes reading a failure report much easier.

Mockito: isolating a unit from the world

Now a real problem. Suppose you have an OrderService that, to place an order, must call a PaymentGateway (which talks to a bank server) and an InventoryRepository (which hits the database). To test this service as a "unit," you don't want to actually call the bank or spin up a database. You want to replace those neighbors with controlled doubles. This is where Mockito comes in.

First, let's build the vocabulary from scratch, because everyone mixes these up:

Setup with JUnit 5

Mockito 5 (latest around 5.23) has an extension for JUnit 5:

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock
    PaymentGateway paymentGateway;      // an automatic double

    @Mock
    InventoryRepository inventory;

    @InjectMocks
    OrderService orderService;          // the mocks above get injected into it

    @Test
    void placesOrderWhenPaymentSucceeds() {
        // arrange: teach the mocks what to say
        when(inventory.isAvailable("book-1", 2)).thenReturn(true);
        when(paymentGateway.charge(anyString(), eq(20.0))).thenReturn(PaymentResult.ok());

        // act
        OrderResult result = orderService.place(new OrderRequest("book-1", 2, "user-9"));

        // assert
        assertTrue(result.isSuccessful());

        // verify interaction: make sure inventory was actually decreased
        verify(inventory).decrease("book-1", 2);
    }
}

@Mock creates an empty double, @InjectMocks builds the real class under test and injects the mocks via constructor or field, and MockitoExtension wires it all up before each test.

when() and thenReturn(): programming the stub

The when(...).thenReturn(...) pattern says "when this method is called with these arguments, return this." Other forms:

// return a value
when(repo.findById(1L)).thenReturn(Optional.of(user));

// throw an exception
when(repo.findById(99L)).thenThrow(new EntityNotFoundException());

// consecutive answers: first this, then that
when(repo.count()).thenReturn(1L, 2L, 3L);

// dynamic answer based on the input
when(repo.save(any(User.class))).thenAnswer(inv -> {
    User u = inv.getArgument(0);
    return new User(42L, u.name());   // as if the DB assigned an id
});

doThrow(new RuntimeException()).when(mock).voidMethod();
doReturn(realValue).when(spy).someMethod();   // safe on a spy

verify(): did the interaction happen correctly?

Some behaviors have no return value; you just need to be sure a thing was done (like sending an email or writing a log). That's where verify comes in:

verify(emailService).send(eq("user@x.com"), anyString()); // exactly once
verify(emailService, times(2)).send(any(), any());        // exactly twice
verify(emailService, never()).send(eq("blocked@x.com"), any()); // never
verify(emailService, atLeastOnce()).send(any(), any());
verify(auditLog, timeout(1000)).record(any());            // within a time window (for async)

// make sure there were no other unexpected interactions
verifyNoMoreInteractions(emailService);

ArgumentCaptor: what exactly was passed?

Sometimes you don't just want to know a method was called, you want to inspect the actual argument that was passed. ArgumentCaptor "captures" that argument so you can assert on it:

import org.mockito.ArgumentCaptor;
import org.mockito.Captor;

@Captor
ArgumentCaptor<EmailMessage> emailCaptor;

@Test
void sendsWelcomeEmailWithRightBody() {
    userService.register(new SignupRequest("Sara", "sara@x.com"));

    verify(emailService).send(emailCaptor.capture());
    EmailMessage sent = emailCaptor.getValue();

    assertEquals("sara@x.com", sent.to());
    assertTrue(sent.body().contains("Welcome, Sara"));
}

Strictness: why Mockito complains about unused stubs

MockitoExtension enables strict stubs by default. That means if you write a when(...) that's never used in the test, Mockito fails it with UnnecessaryStubbingException. This feels annoying but is a gift: an unused stub usually signals that the test doesn't check what you think it does, or the code changed and the test wasn't updated.

Mocking pitfalls

AssertJ: assertions that read like sentences

JUnit's own assertions work, but they have two weaknesses. First, their order is confusing: in assertEquals(expected, actual), which comes first? Everyone gets it wrong once. Second, for complex things (lists, nested fields) they get ugly and uninformative. AssertJ (latest around 3.27.x) is a fluent assertion library that fixes both: you start with assertThat(...) and then chain assertions.

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

@Test
void assertjBasics() {
    String name = "Testcontainers";

    assertThat(name)
        .isNotNull()
        .startsWith("Test")
        .endsWith("ers")
        .hasSize(15)
        .isEqualToIgnoringCase("testcontainers");

    assertThat(2 + 2).isEqualTo(4).isPositive().isEven();
}

Because everything follows assertThat(actual), the order is no longer ambiguous, and the IDE suggests the assertions appropriate for that type after the dot.

The real power: collections and objects

List<String> fruits = List.of("apple", "banana", "cherry");

assertThat(fruits)
    .hasSize(3)
    .contains("banana")
    .doesNotContain("mango")
    .containsExactly("apple", "banana", "cherry")   // in this order
    .allMatch(f -> f.length() > 4);

// extract one field from each object and assert on it
List<Person> people = List.of(new Person("Ali", 30), new Person("Sara", 25));
assertThat(people)
    .extracting(Person::name)
    .containsExactlyInAnyOrder("Sara", "Ali");

// full comparison of two objects without needing a custom equals
assertThat(actualPerson)
    .usingRecursiveComparison()
    .isEqualTo(expectedPerson);

Testing exceptions with AssertJ

assertThatThrownBy(() -> calc.divide(1, 0))
    .isInstanceOf(IllegalArgumentException.class)
    .hasMessageContaining("zero");

// or the more readable alternative
assertThatExceptionOfType(IllegalArgumentException.class)
    .isThrownBy(() -> calc.divide(1, 0))
    .withMessage("division by zero");

Testcontainers: integration testing against real infrastructure

So far we've isolated units. But some things can only be tested properly with the real thing: does my SQL query actually work on Postgres? Do the migrations run? Does my Kafka consumer process the message correctly?

For years people either used in-memory databases like H2 (which doesn't behave exactly like Postgres and hides real bugs), or assumed a database was installed on the developer's machine (brittle and inconsistent). Testcontainers solved this: a library that, during a test, programmatically spins up real Docker containers and tears them down afterward.

A Postgres integration test

import org.junit.jupiter.api.Test;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;
import org.testcontainers.postgresql.PostgreSQLContainer;   // new package in Testcontainers 2.x
import static org.assertj.core.api.Assertions.assertThat;

@Testcontainers
class UserRepositoryIT {

    @Container
    static PostgreSQLContainer<?> postgres =
        new PostgreSQLContainer<>("postgres:17-alpine")
            .withDatabaseName("shop")
            .withUsername("test")
            .withPassword("test");

    @Test
    void savesAndLoadsUser() {
        // the container provides the connection URL (random port)
        String jdbcUrl = postgres.getJdbcUrl();

        var repo = new UserRepository(jdbcUrl, postgres.getUsername(), postgres.getPassword());
        repo.save(new User("Ali", "ali@x.com"));

        assertThat(repo.findByEmail("ali@x.com"))
            .isPresent()
            .get()
            .extracting(User::name)
            .isEqualTo("Ali");
    }
}

Key points: @Testcontainers binds the container lifecycle to JUnit, @Container marks a field as a container. If it's static, it starts up once for the whole class (faster); if it's an instance field, it starts fresh for each test (more isolated). And getMappedPort/getJdbcUrl give the real address, because Testcontainers maps ports to a random free port on the host so parallel tests don't collide.

Testing a Kafka consumer

import org.testcontainers.kafka.KafkaContainer;

@Testcontainers
class OrderEventsIT {

    @Container
    static KafkaContainer kafka = new KafkaContainer("apache/kafka:latest");

    @Test
    void consumesOrderPlacedEvent() {
        String bootstrap = kafka.getBootstrapServers();
        var producer = buildProducer(bootstrap);
        var consumer = buildConsumer(bootstrap, "orders");

        producer.send(new ProducerRecord<>("orders", "order-1", "{\"amount\":50}"));

        var records = consumer.poll(Duration.ofSeconds(5));
        assertThat(records.count()).isEqualTo(1);
    }
}

The same pattern works for Redis, RabbitMQ, Elasticsearch, MongoDB, and even any arbitrary image via GenericContainer.

Wait strategy: wait until it's actually ready

A subtle trap: the container "starts" but the service inside it isn't ready for connections yet. Testcontainers has wait strategies to ensure the service is up before your test runs:

GenericContainer<?> app = new GenericContainer<>("my-api:latest")
    .withExposedPorts(8080)
    .waitingFor(Wait.forHttp("/health").forStatusCode(200));

Ready-made modules (like PostgreSQLContainer) come with the correct wait strategy preconfigured; for GenericContainer you have to specify it yourself.

Flaky tests: the silent enemy of trust

A flaky test is one that sometimes passes and sometimes fails without any code change. These are more dangerous than the bug itself, because they destroy trust: once a team learns to dismiss failures with "just re-run it," they stop taking any failure seriously — and a real bug gets lost in that same noise.

How to hunt them: run the suspect test many times with @RepeatedTest(50) to make it reveal itself, and the moment you spot a flaky test, fix it right there — don't hide it with @Disabled where it stays forever.

Coverage vs meaningful tests

Code coverage is what percentage of lines (or branches) were executed while your tests ran. The common tool in Java is JaCoCo. Coverage is useful, but it has a trap.

Branch coverage is more meaningful than line coverage, because it tells you whether you tested both sides of an if. And if you want to really measure test quality, look at mutation testing with a tool like PIT: it deliberately plants small bugs in the code and checks whether your tests catch them — far more honest than a "coverage percentage."

TDD: test first, code second

Test-Driven Development (TDD) means writing the test before the code. Its cycle is three short steps:

The real benefit of TDD isn't just "having tests"; it's that it forces you to think from the consumer's viewpoint first ("how should this API be called?") and build a more testable design. If writing a test for a class is hard, that usually means the class is badly designed — and TDD tells you this early.

Interview questions