Testes de API REST

Há duas maneiras de errar nos testes de uma API Spring Boot, e elas se parecem menos do que se imagina.

A primeira é não escrever testes. Ninguém assume isso, todo mundo pratica por algum tempo, e o sintoma é conhecido: cada modificação vira uma negociação, porque ninguém sabe o que ela quebra.

A segunda é mais insidiosa porque tem aparência de seriedade. Tudo é anotado com @SpringBootTest, cada teste sobe o contexto completo, a suíte leva onze minutos, a equipe para de executá-la localmente, e metade dos testes verifica que o Spring sabe mapear uma URL — algo que o Spring já garante. Paga-se o preço dos testes sem obter o seu valor: uma suíte lenta que ninguém executa mais não protege de nada.

O bom equilíbrio vem de uma pergunta simples, feita teste a teste: qual código, escrito por mim, este teste protege? Se a resposta é "a lógica de cálculo da data de devolução", um teste unitário de alguns milissegundos basta. Se é "a serialização, a validação e o código de status do meu controller", um slice @WebMvcTest é a ferramenta adequada. Se é "minha consulta JPQL funciona no PostgreSQL", é preciso um PostgreSQL de verdade, e o Testcontainers o fornece.