Use os testes como provas

Comece pelo requisito

Os testes fornecem provas para afirmações específicas. Uma execução bem-sucedida não demonstra todas as propriedades do software. Antes de pedir testes, identifique o comportamento importante e o defeito que cada verificação deve detetar.

Numa exportação fictícia de dados de uma organização, o principal requisito é o isolamento dos dados. Um utilizador da organização A não pode receber registos da organização B. Um teste que apenas verifica uma transferência bem-sucedida não demonstra este requisito.

Peça ao agente que explique a relação entre o requisito e a asserção. Isso facilita a deteção de casos em falta antes de o conjunto de testes crescer.

Escolha o âmbito de teste adequado

Um teste unitário pode verificar rapidamente uma transformação pequena. Um teste de integração pode verificar a colaboração entre componentes. Um teste end-to-end pode verificar uma sequência importante do utilizador na aplicação instalada ou num ambiente representativo.

Use o âmbito mais restrito que forneça as provas necessárias. Um formatador não precisa de um teste completo no browser para cada entrada. Um limite de autorização pode exigir uma rota real e o respetivo acesso aos dados. Uma interação crítica no browser exige provas sobre a interface apresentada.

Não existe uma percentagem fixa de tipos de teste adequada a todos os sistemas. Escolha em função da falha que precisa de detetar e do custo de manutenção da verificação.

Evite um pressuposto incorreto partilhado

Um agente pode escrever a implementação e os testes com base no mesmo equívoco. Ambos podem concordar, enquanto o requisito continua por cumprir.

Imagine que a implementação filtra registos pelo ID de organização fornecido no pedido. O teste usa o mesmo ID para o utilizador autenticado e para o pedido. O teste passa. Falta o caso em que um utilizador pede o ID de outra organização.

Acrescente esse caso através do percurso real de identidade de confiança e autorização. Um mock que devolve sempre «permitido» não demonstra isolamento entre tenants. Demonstra apenas o comportamento após uma autorização bem-sucedida.

Confirme que o teste consegue falhar

Para um defeito conhecido, execute o novo teste de regressão contra a versão defeituosa num branch isolado. Confirme que falha pela razão pretendida. Depois aplique a correção e volte a executá-lo.

Um teste que falha porque não consegue carregar uma fixture ainda não fornece provas sobre o comportamento de negócio. Inspecione a falha, não apenas o código de saída.

Para alterações mais amplas, os testes de mutação podem ajudar a avaliar se certas mudanças de código fazem os testes falhar. Têm um custo e não substituem a revisão de requisitos. Use-os quando as provas adicionais apoiarem uma decisão com consequências relevantes.

Mantenha as provas ligadas à alteração

Execute as verificações relevantes na revisão final do código. Registe as verificações omitidas e os motivos. Um resultado de um commit anterior pode já não se aplicar após uma correção pedida na revisão.

Mantenha os testes compreensíveis. Prefira preparação e asserções explícitas a uma função auxiliar extensa que esconda a condição importante. Remova verificações redundantes quando acrescentarem custo de manutenção sem detetar uma falha diferente.

O revisor deve conseguir explicar o que os testes demonstram e o que continua incerto. Essa explicação é mais útil do que um número elevado de testes.