Testing: JUnit, Mockito & Spring Test Slices

What is an automated test, and why bother?

An automated test is code that checks your other code does the right thing — it runs the code with some input and asserts (insists) the result is what you expect. Run all your tests with one command and you instantly know whether anything broke.

Why employers insist on this: as an app grows, manual clicking cannot cover everything, and a small change can quietly break something far away. Tests catch those breaks the moment they happen. In Spring you write three kinds, from narrow to broad:

A plain unit test with JUnit 5

JUnit 5 is the standard Java testing library (it comes with every Spring Boot project). A test is a method marked @Test; inside it you call your code and use an assertion to state what the answer must be. Say we have a tiny service:

@Service
public class PriceService {
    public double withTax(double price) {
        return price * 1.18;   // add 18% tax
    }
}

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

class PriceServiceTest {

    @Test
    void addsEighteenPercentTax() {
        PriceService service = new PriceService();
        double result = service.withTax(1000);
        // assert: the result MUST equal 1180
        assertEquals(1180.0, result);
    }
}

Testing a service that needs a repository: Mockito

Most services depend on a repository — but in a unit test we do not want to touch a real database (slow, and a database failure should not fail a logic test). The solution is a mock: a fake stand-in object that returns exactly what we tell it to. Mockito is the standard mocking library.

Say a ProductService fetches a product and throws if it is missing. We mock the repository so the test is fast and focused purely on the service’s logic:

import static org.mockito.Mockito.when;
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
import java.util.Optional;

class ProductServiceTest {

    @Test
    void returnsProductWhenItExists() {
        // 1) create a FAKE repository
        ProductRepository repo = Mockito.mock(ProductRepository.class);
        // 2) tell the fake what to return for findById(1)
        when(repo.findById(1L))
            .thenReturn(Optional.of(new Product("Mouse", 499.0)));

        ProductService service = new ProductService(repo);

        // 3) call the real service (it uses the fake repo)
        Product p = service.getProduct(1L);

        // 4) assert the logic did the right thing
        assertEquals("Mouse", p.getName());
    }
}

Testing a controller with @WebMvcTest and MockMvc

To test a controller — the web layer — Spring gives you a slice test. @WebMvcTest starts only the web layer (not the database), and MockMvc lets you send fake HTTP requests and check the response, without a running server.

@WebMvcTest(ProductController.class)
class ProductControllerTest {

    @Autowired MockMvc mockMvc;          // sends fake HTTP requests
    @MockBean ProductService service;     // a mock of the service it depends on

    @Test
    void getReturnsProductJson() throws Exception {
        when(service.getProduct(1L))
            .thenReturn(new Product("Mouse", 499.0));

        mockMvc.perform(get("/products/1"))
            .andExpect(status().isOk())                       // 200
            .andExpect(jsonPath("$.name").value("Mouse"));    // body check
    }
}

The other slices, in one line each

• @DataJpaTest — tests just your repository/JPA layer against a fast in-memory database, so you can verify a custom query really works.
• @SpringBootTest — starts the whole application context for a full integration test, when you want to check that all the layers work together end to end.