Planejamento de testes

Ao iniciar um projeto de testes automatizados (ou evoluir um projeto existente), gosto de começar me fazendo as seguintes perguntas:

1. "Qual é a principal funcionalidade da aplicação, aquela que, se não funcionar, não atende às necessidades dos usuários?"
2. "Quais casos de teste serão implementados?"
3. "Quais testes são mais importantes e devem ser priorizados?"
4. "Quais testes podem ficar para depois?"
5. "Que tipos de teste serão escritos? De ponta a ponta? De acessibilidade?"

Ao responder essas perguntas, ganho insights valiosos para iniciar o que chamo de processo criativo na escrita de testes automatizados.

Depois, começo um processo exploratório da aplicação (ou funcionalidade) que será testada.

Nesse momento, além de descobrir como a aplicação se comporta atualmente, também descubro edge cases, que às vezes podem ser esquecidos durante o desenvolvimento da aplicação.

Então, sem mais delongas, abro o editor de código e começo a escrever um "esqueleto" 💀 da suíte de testes. Apenas as descrições dos casos de teste, sem detalhes de implementação.

Estruturando suítes de teste com o Cypress

No Cypress, os casos de teste são organizados em uma suíte de teste.

A forma mais comum de definir uma suíte de teste é usando duas funções diferentes.

Elas são as funções describe() e it() do mocha.

Elas recebem uma string como primeiro argumento e uma função de callback como segundo argumento.

O primeiro argumento do describe é a descrição da suíte de teste (por exemplo, 'Autenticação', 'Busca de produtos', 'Lista de usuários', etc.)

Os casos de teste são definidos dentro da função de callback (o seu segundo argumento).

A função it() define um caso de teste.

O primeiro argumento do it é a descrição do caso de teste (por exemplo, 'faz login com sucesso', 'busca por um produto inexistente', 'lista os dez primeiros usuários', etc.)

Os detalhes de implementação do teste ficam dentro da função de callback (o seu segundo argumento).

A seguir está um exemplo do esqueleto de uma suíte de teste com alguns casos de teste.

describe('Authentication', () => {
  it('successfully logs in', () => {
    // test implementation here.
  })

  it('successfully logs out', () => {
    // test implementation here.
  })
})

Exercício 🎯

Com base no processo sugerido acima, crie um "esqueleto" dos testes que você considera essenciais para garantir que a aplicação Cypress Simulator funcione conforme o esperado, dando assim ao time a confiança de que, se todos os testes estiverem verdes, ela pode ser entregue em produção para uso.

Mostre ao mundo o que você aprendeu 🌎

Para mostrar à sua rede profissional o que você aprendeu nesta aula, publique o seguinte no LinkedIn.

Estou fazendo o curso Cypress Simulator com @Walmyr Lima e Silva Filho na @Talking About Testing School, onde aprendi um processo prático de planejamento de testes automatizados que me ajuda a priorizar os testes mais importantes e a ter algo concreto para trabalhar. #TalkingAboutTesting #TATSchool #CypressSimulator #Cypress

👨‍🏫 Lembre-se de me marcar na sua publicação. Aqui está o meu perfil no LinkedIn.