Testes Unitários em API REST com Spring Boot
A estruturar testes eficazes com MockMvc, arquitetura em camadas e DTOs.
Por que isso é importante
Testes Unitários em API REST com Spring Boot. A estruturar testes eficazes com MockMvc, arquitetura em camadas e DTOs.
Relembrando o Desafio Backend
No desafio em questão, desenvolvemos uma API REST composta por três endpoints
principais: agendamento de comunicação, consulta de status e remoção de agendamento. O
sistema aceita envios por e-mail, SMS, push ou WhatsApp, e os requests incluem
data/hora, destinatário e mensagem.
Arquitetura em Camadas Adotada
Foi seguida a estrutura com Models, Repository, Service e Controller:
- Model: Entidade de agendamento com anotações JPA e uso de
@Builder. - Repository: Interface que manipula o banco via Spring Data JPA.
- Service: Camada de lógica que transforma DTOs em entidades e
implementa regras como exceções personalizadas e validação de IDs. - Controller: Exposto com rotas POST, GET e DELETE, sem regra de
negócio. Apenas comunicação com service e retorno HTTP adequado.
Organizando a Suite de Testes com MockMvc
Para testar os endpoints, utilizamos o @WebMvcTest com MockMvc, o que permite simular
requisições HTTP reais sem necessidade de subir o banco de dados ou a aplicação inteira.
A classe de teste se concentra em testar a interface REST, mockando a camada de service
para isolar o comportamento esperado dos endpoints.
Principais Dependências no Teste
MockMvc
Simulador de requisições HTTP para testar endpoints.
ObjectMapper
Utilitário para conversão entre objetos Java e JSON.
@WebMvcTest
Foca no teste de Controllers isoladamente.
@MockBean
Mocka a camada de Service para controle do comportamento esperado.
Simulando Requisições POST
Um teste clássico de criação de agendamento utiliza:
- Passo 1: Criar DTO com os dados do request: destinatário,
mensagem, tipo e data. - Passo 2: Criar DTO esperado do response com ID simulado e
status de agendamento. - Passo 3: Configurar o when().thenReturn() do mock de service
para retornar esse DTO. - Passo 4: Usar o mockMvc.perform() com método POST, content-type
JSON e body convertido com ObjectMapper. - Passo 5: Validar status HTTP 200 OK e o conteúdo do JSON
retornado com os campos esperados.
Atenção
Evite colocar validações e regra de negócio diretamente nos controllers. Mantenha essa
responsabilidade na camada Service para garantir testabilidade e separação de
responsabilidades.
Testando Endpoints GET e DELETE
O padrão se repete para os outros métodos. Para GET, usamos o mockMvc.perform(get(...))
e para DELETE, mockMvc.perform(delete(...)). Em ambos os casos, configuramos o retorno
simulado no service.
Dica
Use métodos como .andExpect(status().isOk()) e
.andExpect(jsonPath("$.campo").value(valorEsperado)) para validações claras no retorno
da sua API.
Melhores Práticas nos Testes
Adote nomes claros para os métodos de teste (ex: deveAgendarComunicacao), organize os
imports, evite dependência do banco e mantenha testes rápidos e independentes.
Evite Erros Comuns
Não misture testes unitários com integração no mesmo escopo. Para cada tipo de
validação (dados, controller, negócio), use o nível de teste apropriado.
Automatização Futuramente
Com a base unitária sólida, podemos evoluir para testes de integração completos com
@SpringBootTest e bibliotecas como Testcontainers para ambientes reais em CI/CD.
Checklist de Implementação
- Criou DTOs de request e response
- Aplicou arquitetura com camadas separadas
- Adicionou suite de testes com MockMvc
- Utilizou @MockBean na camada de Service
- Verificou status HTTP e conteúdo dos retornos JSON
- Executou os testes com sucesso no IntelliJ