Springboot Tdd

Spring Boot TDD is an AI skill that provides test-driven development patterns for building Spring Boot applications where tests are written before implementation code. It covers red-green-refactor cycles, controller testing with MockMvc, service layer testing with mocks, repository testing with test databases, and integration test strategies that enable reliable Spring Boot development.

What Is This?

Overview

Spring Boot TDD provides structured approaches to developing Spring applications test-first. It handles writing failing tests that define expected behavior before implementing features, testing REST controllers with MockMvc to verify request mapping and response formatting, testing service classes with mocked dependencies for isolated business logic verification, testing repository queries against in-memory or containerized databases, composing integration tests that verify full request-to-database flows, and organizing test classes with consistent naming and structure conventions.

Who Should Use This

This skill serves Java developers adopting TDD practices in Spring Boot projects, backend teams establishing test-first development standards, QA engineers writing tests at multiple abstraction layers, and tech leads improving code quality through test-driven workflows.

Why Use It?

Problems It Solves

Writing tests after implementation often results in tests that verify implementation details rather than behavior. Without TDD, developers may skip edge case testing for paths they did not consider during implementation. Untested Spring configurations cause runtime failures discovered only during deployment. Large pull requests without tests create review burden and regression risk.

Core Highlights

Red-green-refactor cycles ensure every feature has tests before implementation exists. MockMvc testing validates controller request mapping, serialization, and response behavior without starting a full server. Service isolation through mocking tests business logic independently of infrastructure. Test slices such as @WebMvcTest and @DataJpaTest load only the required Spring context for faster test execution.

How to Use It?

Basic Usage

@WebMvcTest(UserController.class)
class UserControllerTest {
    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private UserService userService;

    @Test
    void shouldReturnUserById() throws Exception {
        User user = new User("1", "alice@test.com", "Alice");
        when(userService.getUser("1")).thenReturn(user);

        mockMvc.perform(get("/api/users/1"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.name").value("Alice"))
            .andExpect(jsonPath("$.email").value("alice@test.com"));
    }

    @Test
    void shouldReturn404WhenUserNotFound() throws Exception {
        when(userService.getUser("999"))
            .thenThrow(new NotFoundException("User not found"));

        mockMvc.perform(get("/api/users/999"))
            .andExpect(status().isNotFound())
            .andExpect(jsonPath("$.code").value("NOT_FOUND"));
    }

    @Test
    void shouldCreateUser() throws Exception {
        User created = new User("2", "bob@test.com", "Bob");
        when(userService.register("bob@test.com", "Bob"))
            .thenReturn(created);

        mockMvc.perform(post("/api/users")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{\"email\":\"bob@test.com\",\"name\":\"Bob\"}"))
            .andExpect(status().isCreated())
            .andExpect(jsonPath("$.id").value("2"));
    }
}

Real-World Examples

@ExtendWith(MockitoExtension.class)
class UserServiceTest {
    @Mock
    private UserRepository repository;

    @InjectMocks
    private UserService service;

    @Test
    void shouldRegisterNewUser() {
        when(repository.findByEmail("new@test.com"))
            .thenReturn(Optional.empty());
        when(repository.save(any(User.class)))
            .thenAnswer(inv -> inv.getArgument(0));

        User result = service.register("new@test.com", "New User");

        assertThat(result.getEmail()).isEqualTo("new@test.com");
        verify(repository).save(any(User.class));
    }

    @Test
    void shouldRejectDuplicateEmail() {
        when(repository.findByEmail("taken@test.com"))
            .thenReturn(Optional.of(new User()));

        assertThatThrownBy(() ->
            service.register("taken@test.com", "Dup"))
            .isInstanceOf(ConflictException.class);
    }
}

@DataJpaTest
class UserRepositoryTest {
    @Autowired
    private UserRepository repository;

    @Autowired
    private TestEntityManager entityManager;

    @Test
    void shouldFindByEmail() {
        User user = new User();
        user.setEmail("find@test.com");
        user.setName("Finder");
        entityManager.persist(user);
        entityManager.flush();

        Optional<User> found = repository.findByEmail("find@test.com");

        assertThat(found).isPresent();
        assertThat(found.get().getName()).isEqualTo("Finder");
    }
}

Advanced Tips

Use @WebMvcTest for controller slices and @DataJpaTest for repository slices to minimize context loading time. Apply the Arrange-Act-Assert pattern consistently for readable test structure. Use Testcontainers for integration tests that need a real database engine.

When to Use It?

Use Cases

Use Spring Boot TDD when developing new features test-first to ensure complete coverage, when testing REST API behavior at the controller layer with MockMvc, when verifying business logic in isolation from Spring infrastructure, or when validating repository queries against test data.

Related Topics

JUnit 5 and Mockito usage, Spring test slices, Testcontainers integration, AssertJ fluent assertions, and test-driven refactoring techniques complement Spring Boot TDD.

Important Notes

Requirements

Spring Boot 3.x with spring-boot-starter-test dependency. JUnit 5 and Mockito for unit testing. H2 or Testcontainers for repository tests.

Usage Recommendations

Do: write the test before the implementation to ensure design is driven by requirements. Use test slices to load minimal context and keep test execution fast. Verify both success and error paths in every layer.

Don't: write tests that verify implementation details like method call counts without behavior context. Load the full Spring context for every test, which slows the suite. Skip the refactor step, which accumulates technical debt in both test and production code.

Limitations

TDD requires discipline and adds initial development time before delivering productivity benefits through reduced debugging. MockMvc tests do not cover the full servlet container stack. Test slices may miss configuration issues that only appear with the full application context.