Boas práticas de Testes Unitários: Arrange, Act, Assert
Os testes unitários são escritos com o objetivo de obter maior qualidade na entrega de um software e facilidade em sua manutenção. Porém, se após alguma modificação um teste falhar, e esse estiver mal escrito, o desenvolvedor terá dois problemas: O código que agora não funciona como deveria e por isso o teste falhou e o próprio teste que está de difícil de ser compreendido.
Por isso, não basta construir testes unitários, é necessário construir testes unitários de qualidade.
Um código de qualidade requer organização e quando se fala de organização de teste unitário um padrão muito adotado é o Triple A ou AAA. Esse padrão prega que devemos estruturar os nossos testes em 3 passos: Arrange, Act e Assert (AAA).
Arrange
Nesse passo deve ser estruturado todo o cenário para a execução do teste, é onde serão criados os objetos que serão passados como parâmetro na função ou método a ser testado.
Exemplo: Em caso de estarmos testando uma função ou método de cadastro de produto, que recebe como parâmetro um objeto produto, é neste momento que faremos a criação desse objeto.
Em caso de uso de mocks, é neste passo que eles devem ser definidos.
Act
Nesse passo deve ser realizada a execução do teste em si, é onde será a acionada a função ou o método a ser testado.
Exemplo: Seguindo o mesmo exemplo, é agora que acionaremos o método responsável por realizar o cadastro do produto passando como parâmetro o objeto criado no passo anterior.
Assert
No ultimo passo deve ser verificado se o resultado do teste está de acordo com o que é esperado.
Exemplo: Agora verificaremos se o código do novo produto foi retornado, ou seja, se o produto foi criado efetivamente.
Em caso de uso de mocks, é nesse passo que deve ser verificado se todos os métodos ou funções que seriam acionados, ou não, foram invocados.
Esse padrão pode parecer algo muito intuitivo, mas acredite existem diversos testes unitários criados por aí que ainda no passo de Arrange já realizam verificações, obviamente em cenários de teste complexos que não é o caso do nosso exemplo.
Com a adoção desse padrão de organização conseguimos garantir que os nossos testes estarão estruturados de forma organizada para facilitar o entendimento de outros desenvolvedores em futuras manutenções.
Espero ter conseguido te ajudar!
Caso você ainda não tenha visto, tenho outro artigo falando da importância da adoção de um padrão para definição do nome dos testes unitários: https://hyago.dev/nao-cometa-o-erro-de-descrever-o-seu-teste-unitario-dessa-forma/
Até a próxima, abraços!