Use testes como evidência

Comece pelo requisito

Testes são evidências de afirmações específicas. Uma execução de testes bem-sucedida não comprova todas as propriedades do software. Antes de pedir testes, identifique o comportamento importante e o defeito que cada verificação deve detectar.

Em uma exportação fictícia por organização, o requisito principal é o isolamento de dados. Um usuário da organização A não deve receber registros da organização B. Um teste que verifica apenas um download bem-sucedido não comprova esse requisito.

Peça ao agente que explique a relação entre o requisito e a asserção. Isso facilita a identificação de casos ausentes antes que a suíte de testes cresça.

Escolha o escopo de teste adequado

Um teste unitário pode verificar rapidamente uma pequena transformação. Um teste de integração pode verificar como os componentes funcionam juntos. Um teste de ponta a ponta pode verificar uma sequência importante do usuário na aplicação implantada ou em uma versão representativa.

Use o escopo mais restrito que forneça a evidência necessária. Um formatador não precisa de um teste completo de navegador para cada entrada. Um limite de autorização pode exigir uma rota real e um caminho real de acesso a dados. Uma interação crítica no navegador precisa de evidências sobre a interface renderizada.

Nenhum percentual fixo de tipos de teste serve para todos os sistemas. Escolha com base na falha que precisa detectar e no custo de manter a verificação.

Evite uma premissa incorreta compartilhada

Um agente pode escrever a implementação e os testes a partir do mesmo entendimento errado. Os dois podem concordar enquanto o requisito continua sem ser atendido.

Suponha que a implementação filtre registros pelo ID de organização fornecido na requisição. O teste usa o mesmo ID para o usuário autenticado e para a requisição. Ele passa. O caso ausente é um usuário que solicita o ID de outra organização.

Acrescente esse caso usando a identidade confiável real e o caminho real de autorização. Um mock que sempre retorna “permitido” não pode comprovar o isolamento entre tenants. Ele comprova apenas o comportamento após uma autorização bem-sucedida.

Verifique se o teste pode falhar

Para um defeito conhecido, execute o novo teste de regressão contra a versão defeituosa em uma branch isolada. Confirme que ele falha pelo motivo esperado. Depois, aplique a correção e execute-o novamente.

Um teste que falha porque uma fixture não carrega ainda não é evidência sobre o comportamento de negócio. Inspecione a falha, não apenas o código de saída.

Em alterações mais amplas, testes de mutação podem ajudar a avaliar se determinadas alterações no código fazem os testes falharem. Eles têm um custo e não substituem a revisão de requisitos. Use-os quando a evidência adicional apoiar uma decisão relevante.

Mantenha as evidências vinculadas à alteração

Execute as verificações relevantes na revisão final. Registre as verificações não executadas e seus motivos. Um resultado de um commit anterior pode deixar de ser válido após uma correção de revisão.

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

O revisor deve conseguir dizer o que os testes comprovam e o que continua incerto. Essa explicação é mais útil que um grande número de testes.