- Entenda a importância dos testes automatizados no código
- Utilize o JUnit como biblioteca de testes automatizados
- Escreva testes de unidade com JUnit
- Simule comportamentos nos testes com a biblioteca Mockito
- Aprenda a testar classes service e controller do Spring
- Testes de unidade com JUnit
- Boas práticas em testes
- Testes com Mockito
- Testes automatizados em Services
- Testes automatizados em Controllers
- Desafios
https://cursos.alura.com.br/course/boas-praticas-programacao-testes-java
Java 21 : Utilizaremos a versão LTS mais recente do Java para tirar vantagem das últimas inovações que essa linguagem robusta e amplamente utilizada oferece;
Spring Boot 3 : Trabalharemos com a mais nova versão do Spring Boot, que maximiza a produtividade do desenvolvedor por meio de sua poderosa premissa de autoconfiguração;
My SQL: Banco de dados MySQL.
Postman: Para testar os métodos http do controller.
Junit 5: Para fazer os teste unitários
Ao escrever testes automatizados é importante pensar em como organizar o código de cada teste, de forma que fique bem fácil de entender cada cenário sendo testado. Para facilitar esse processo, existem alguns padrões de organização do código de cada cenário de teste que podem ser utilizados para ajudar nesse objetivo.
Dois padrões são os mais comuns na organização de testes automatizados: "Arrange, Act, Assert" (conhecido como AAA ou Triple A) e "Given, When, Then" (conhecido como GWT). Ambos os padrões têm o objetivo de tornar os testes mais legíveis e fáceis de entender, promovendo uma abordagem estruturada na criação de cenários de teste.
O padrão AAA é amplamente utilizado e consiste em três etapas distintas:
a) Arrange (Preparar): Nesta etapa, são realizadas todas as configurações iniciais necessárias para que o cenário de teste possa ser executado. Isso pode incluir a criação de objetos, definição de variáveis, configuração de ambiente e qualquer outra preparação necessária para que o teste seja executado em um estado específico.
b) Act (Agir): Nesta fase, a ação que se deseja testar é executada. Pode ser a chamada de um método, uma interação com a interface do usuário ou qualquer outra operação que seja o foco do teste.
c) Assert (Verificar): Na última etapa, os resultados são verificados em relação ao comportamento esperado. É onde se avalia se o resultado obtido após a ação está de acordo com o que se esperava do teste. Caso haja alguma discrepância entre o resultado real e o esperado, o teste falhará.
O padrão GWT também é conhecido como padrão BDD (Behavior-Driven Development). Ele foi projetado para criar testes com uma linguagem mais próxima da forma como os cenários são discutidos entre as pessoas que fazem parte do projeto, incluindo pessoas técnicas, como desenvolvedores e testadores, além de clientes e usuários da aplicação. O padrão GWT tem as seguintes etapas:
a) Given (Dado): Nesta etapa, é descrito o cenário inicial ou o contexto do teste. São definidas as condições iniciais necessárias para a execução do cenário de teste.
b) When (Quando): Aqui, a ação específica que está sendo testada é executada. É a etapa em que a ação do usuário ou do sistema acontece.
c) Then (Então): Nesta etapa, os resultados esperados são verificados. São definidos os critérios de sucesso para o cenário de teste, e o teste é aprovado ou reprovado com base nesses resultados.
Ambos os padrões tornam os testes mais fáceis de ler e entender, mesmo para pessoas não familiarizadas com o código ou com a lógica de negócios do sistema. Além disso, a estruturação dos testes em etapas claras e definidas torna mais fácil para as pessoas desenvolvedoras localizarem e corrigirem problemas em caso de falha.