Por que isso é importante

Dominar testes unitários é crucial para garantir a qualidade e robustez de uma API REST. Com o uso de frameworks como o Spring Boot e ferramentas como MockMvc, é possível testar endpoints de forma isolada, reduzindo riscos e aumentando a produtividade do time de desenvolvimento.

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

Testes Unitários em API REST com Spring Boot