Testing — JUnit 5 and Mockito

Why Testing Matters — and the Trap Most Test Suites Fall Into

Automated tests exist to answer one question with confidence: "does the code actually do what it's supposed to do?" The trap — and it's an extremely common one, even among developers fluent in JUnit and Mockito syntax — is writing a test that makes the code pass through without ever actually checking that it did the right thing. A test suite full of syntactically correct tests that don't verify real behavior is worse than no tests at all, because it gives everyone false confidence to refactor and deploy.

The Testing Pyramid

         /\
        /  \         E2E Tests (few) — full system, slowest
       /----\
      /      \       Integration Tests (some) — real collaborators at the boundary
     /--------\
    /          \     Unit Tests (many) — fast, isolated, the bulk of your suite
   /------------\

Tests That Pass But Don't Test Anything

This is the single most common way an experienced team ends up with "100% coverage" and production bugs anyway. Three concrete failure patterns, and how to actually catch them.

1. Tautological assertions

// LOOKS like a test. Verifies almost nothing.
@Test
void createOrder() {
    Order result = orderService.createOrder(request);
    assertNotNull(result);   // passes even if total, status, and items are all wrong
}

// ACTUALLY tests the behavior a caller depends on
@Test
void createOrder_calculatesCorrectTotal() {
    Order result = orderService.createOrder(request);

    assertEquals(OrderStatus.CREATED, result.getStatus());
    assertEquals(new BigDecimal("59.98"), result.getTotal());
    assertEquals(2, result.getItems().size());
}

2. Over-mocking — the test verifies the implementation, not the outcome

// This test mocks every collaborator so thoroughly that it just re-describes
// the method body, line by line, instead of checking what the caller
// actually cares about: did the order get created correctly?
@Test
void createOrder_overSpecified() {
    orderService.createOrder(request);

    verify(inventoryService).checkAvailability("item-1", 2);
    verify(pricingService).calculateSubtotal(any());
    verify(taxService).calculateTax(any());
    verify(paymentService).process(any());
    verify(orderRepository).save(any());
    verify(auditLog).record(any());
    // Reorder these calls harmlessly inside createOrder(), or inline one of
    // these collaborators — this test breaks, even though the actual output
    // (the returned Order) never changed. It's coupled to HOW, not WHAT.
}

// Verify only the interactions that represent a real side effect the
// caller depends on — not every internal step
@Test
void createOrder_persistsAndCharges() {
    Order result = orderService.createOrder(request);

    assertEquals(OrderStatus.CREATED, result.getStatus());
    verify(orderRepository).save(any(Order.class));   // a real side effect callers rely on
    verify(paymentService).process(any());                        // same
    // No assertions about pricing/tax internals — those get their own
    // focused unit tests on PricingService and TaxService directly.
}

3. The mutation testing gut check

Here's the honest question coverage tools can't answer: if you deleted a business rule from the code, would any test actually fail? Coverage only tells you a line executed — not that a test would notice if that line's logic were wrong or missing entirely.

public void validateOrder(Order order) {
    if (order.getTotal().compareTo(BigDecimal.ZERO) <= 0) {
        throw new InvalidOrderException("Total must be positive");
    }
}
// If your test suite only ever exercises this method with a valid,
// positive-total order, this line has 100% line coverage — and a test
// suite that would pass identically if you deleted the entire if-block.

<!-- pom.xml -->
<plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>
    <version>1.15.8</version>
    <configuration>
        <targetClasses>
            <param>com.shop.order.*</param>
        </targetClasses>
    </configuration>
</plugin>

mvn org.pitest:pitest-maven:mutationCoverage
# Report shows KILLED vs SURVIVED mutants per class — a surviving mutant
# on a conditional you thought was tested is a direct signal to add a
# test for the missing branch.

Real Network Calls Leaking Into Your Test Suite

The other classic way "tests" quietly become something worse than useless: a test that hardcodes a real URL — localhost:8080, a real payment gateway sandbox, a real third-party API — and makes an actual network call every single time the suite runs. This makes tests slow, flaky (they fail when the network or the third party is down, not when your code is wrong), and occasionally dangerous (a "test" that accidentally hits a production endpoint).

// BAD — a "unit" test that makes a real HTTP call on every run
@Test
void chargePayment() {
    RestTemplate restTemplate = new RestTemplate();
    PaymentResponse response = restTemplate.postForObject(
        "http://localhost:8080/payment-gateway/charge",   // real call, real dependency, every run
        request, PaymentResponse.class);
    assertTrue(response.isSuccessful());
    // Fails if the gateway isn't running locally. Fails differently in CI.
    // Says nothing reliable about YOUR code's correctness.
}

For pure unit tests — mock the collaborator, never the network

If PaymentService is a Spring bean wrapping the HTTP call, mock PaymentService itself with Mockito, exactly as covered in Section 6 — there's no reason a unit test for OrderService should know an HTTP call is involved at all.

For integration tests that must exercise real HTTP wiring — use WireMock

<!-- pom.xml -->
<dependency>
    <groupId>org.wiremock</groupId>
    <artifactId>wiremock-standalone</artifactId>
    <version>3.9.1</version>
    <scope>test</scope>
</dependency>

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class PaymentServiceIntegrationTest {

    static WireMockServer wireMockServer = new WireMockServer(0);   // random free port — never hardcoded

    @BeforeAll
    static void startWireMock() {
        wireMockServer.start();
        configureFor("localhost", wireMockServer.port());
    }

    @AfterAll
    static void stopWireMock() { wireMockServer.stop(); }

    @Test
    void chargePayment_gatewaySucceeds() {
        stubFor(post(urlEqualTo("/charge"))
            .willReturn(aResponse()
                .withStatus(200)
                .withHeader("Content-Type", "application/json")
                .withBody("{\"successful\": true, \"transactionId\": \"tx-123\"}")));

        PaymentResponse response = paymentService.charge(request);

        assertTrue(response.isSuccessful());
        verify(postRequestedFor(urlEqualTo("/charge")));   // confirms the real HTTP call shape, no real network
    }
}

For database integration tests — Testcontainers, never a real localhost service

Pointing an integration test's datasource URL at jdbc:postgresql://localhost:5432/mydb means the test only passes on machines that happen to have a Postgres instance running locally with matching credentials — it's not reproducible, and it silently passes against whatever schema state that local database happens to be in.

@Testcontainers
@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class CustomerRepositoryTest {

    @Container
    static PostgreSQLContainer<?> postgres =
        new PostgreSQLContainer<>("postgres:16-alpine");   // a real, disposable Postgres — same engine as production

    @DynamicPropertySource
    static void configure(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }

    @Autowired
    private CustomerRepository customerRepository;

    @Test
    void findByEmail_customerExists_returnsCustomer() {
        customerRepository.save(new Customer("jane@shop.com", "Jane Doe"));

        Optional<Customer> found = customerRepository.findByEmail("jane@shop.com");

        assertTrue(found.isPresent());
        assertEquals("Jane Doe", found.get().getFullName());
    }
}

JUnit 5 Fundamentals

Maven Dependencies

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.11.0</version>
    <scope>test</scope>
</dependency>

Basic Test Structure

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

class DiscountCalculatorTest {

    private DiscountCalculator calculator;

    @BeforeEach
    void setUp() {
        calculator = new DiscountCalculator();
    }

    @Test
    @DisplayName("Applies a 10% discount to orders over $100")
    void appliesDiscountAboveThreshold() {
        BigDecimal result = calculator.apply(new BigDecimal("200.00"));
        assertEquals(new BigDecimal("180.00"), result);
    }

    @Test
    @DisplayName("Rejects a negative order total")
    void rejectsNegativeTotal() {
        assertThrows(IllegalArgumentException.class,
            () -> calculator.apply(new BigDecimal("-1")));
    }
}

Common Assertions

assertEquals(expected, actual);
assertThrows(IllegalArgumentException.class, () -> service.process(null));
assertAll("Customer properties",
    () -> assertEquals("Jane", customer.getFullName()),
    () -> assertNotNull(customer.getEmail())
);

Lifecycle Annotations

@BeforeAll  static void initAll() { }    // once, before all tests in the class
@BeforeEach void init() { }         // before every test — fresh state, no leakage between tests
@AfterEach  void tearDown() { }     // after every test
@AfterAll   static void tearDownAll() { } // once, after all tests
@Disabled("Blocked on PAY-1421") // skip with a reason, not silently

Parameterized Tests

@ParameterizedTest
@CsvSource({
    "100.00, 90.00",   // above threshold — discounted
    "50.00, 50.00",    // below threshold — unchanged
    "100.01, 90.01"    // boundary — exactly above
})
void applyDiscount_variousTotals(BigDecimal input, BigDecimal expected) {
    assertEquals(expected, calculator.apply(input));
}

@ParameterizedTest
@MethodSource("provideCustomers")
void isValid_variousCustomers(Customer customer, boolean expected) {
    assertEquals(expected, validator.isValid(customer));
}

static Stream<Arguments> provideCustomers() {
    return Stream.of(
        Arguments.of(new Customer("jane@shop.com", "Jane"), true),
        Arguments.of(new Customer("invalid-email", "Jane"), false)
    );
}

Boundary cases (like the 100.01 row above) matter more than adding a fourth arbitrary "normal" value — this is exactly the kind of case a surviving mutant from Section 1 tends to expose.

Mockito

Maven Dependencies

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>5.14.0</version>
    <scope>test</scope>
</dependency>

Creating Mocks

@ExtendWith(MockitoExtension.class)
class CustomerServiceTest {

    @Mock  private CustomerRepository customerRepository;
    @InjectMocks private CustomerService customerService;

    @Test
    void findById_customerExists_returnsCustomer() {
        Customer mockCustomer = new Customer(1L, "Jane");
        when(customerRepository.findById(1L)).thenReturn(Optional.of(mockCustomer));

        Customer result = customerService.findById(1L);

        assertEquals("Jane", result.getFullName());
    }
}

Stubbing and Verification

when(repository.findById(1L)).thenReturn(Optional.of(customer));
when(service.process(null)).thenThrow(new IllegalArgumentException());
doThrow(new RuntimeException()).when(service).dangerousMethod();

verify(repository, times(1)).save(any());
verify(repository, never()).delete(any());

// ArgumentCaptor — inspect what was actually passed, not just that it was called
ArgumentCaptor<Customer> captor = ArgumentCaptor.forClass(Customer.class);
verify(repository).save(captor.capture());
assertEquals("Jane", captor.getValue().getFullName());

A Complete, Well-Scoped Test Class

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock private OrderRepository orderRepository;
    @Mock private PaymentService paymentService;
    @Mock private InventoryService inventoryService;
    @InjectMocks private OrderService orderService;

    @Nested
    @DisplayName("When creating an order")
    class CreateOrder {

        @Test
        @DisplayName("succeeds and persists the order with a CREATED status")
        void createOrderSuccess() {
            OrderRequest request = new OrderRequest("item-1", 2);
            when(inventoryService.checkAvailability("item-1", 2)).thenReturn(true);
            when(paymentService.process(any())).thenReturn(PaymentResult.success());

            Order result = orderService.createOrder(request);

            assertEquals(OrderStatus.CREATED, result.getStatus());
            verify(orderRepository).save(any(Order.class));
        }

        @Test
        @DisplayName("throws and never attempts payment when inventory is insufficient")
        void createOrderItemNotAvailable() {
            OrderRequest request = new OrderRequest("item-1", 100);
            when(inventoryService.checkAvailability("item-1", 100)).thenReturn(false);

            assertThrows(InsufficientInventoryException.class,
                () -> orderService.createOrder(request));

            verify(paymentService, never()).process(any());   // a real business rule, legitimately verified
        }
    }
}

Integration Testing with Spring Boot

@SpringBootTest
@AutoConfigureMockMvc
class CustomerControllerIntegrationTest {

    @Autowired private MockMvc mockMvc;
    @Autowired private ObjectMapper objectMapper;

    @Test
    void createCustomer_validRequest_returnsCreated() throws Exception {
        CustomerDTO customer = new CustomerDTO("Jane", "jane@shop.com");

        mockMvc.perform(post("/api/customers")
                .contentType(MediaType.APPLICATION_JSON)
                .content(objectMapper.writeValueAsString(customer)))
            .andExpect(status().isCreated())
            .andExpect(jsonPath("$.email").value("jane@shop.com"));
    }
}

See Section 2 for how to keep the database and any downstream HTTP calls behind this kind of test real but not machine-dependent, via Testcontainers and WireMock.

Test Coverage — and Its Real Limits

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.12</version>
    <executions>
        <execution><goals><goal>prepare-agent</goal></goals></execution>
        <execution><id>report</id><phase>test</phase><goals><goal>report</goal></goals></execution>
    </executions>
</plugin>

Best Practices and Common Pitfalls

Interview Questions