Escrever um teste unitário bom e reportar um bug de forma que o time consiga agir são a mesma disciplina aplicada em dois momentos diferentes: comunicar com clareza o que aconteceu, e o que deveria ter acontecido.

Este é um guia curto para estruturar um teste, escolher test doubles e registrar um bug de um jeito reproduzível.

1. Comece com um teste unitário claro

Um resumo direto de boas práticas de PHPUnit:

  1. Seja descritivo sobre o que está testando.
  2. Seja explícito sobre o que está testando.
  3. Use a assertion mais específica possível — assertCount(3, $items) em vez de assertTrue(count($items) === 3).
  4. Desacople código de teste de dado de teste. Se o dado muda, o teste não deveria precisar mudar junto.
  5. Use um arquivo de configuração em vez de espalhar setup manual pelos testes.
  6. Escreva testes unitários de verdade — use stub e mock quando fizer sentido, não como reflexo automático.

2. Organize o teste com o padrão Triple A

  • Arrange: prepara o teste — variáveis, mocks, spies.
  • Act: roda o que está sendo testado.
  • Assert: verifica se o resultado bate com o esperado.

Separar essas três etapas visualmente no código — mesmo que só com uma linha em branco entre elas — já deixa o teste mais fácil de ler seis meses depois.

3. Escolha entre stub e mock

  • Stub: um objeto falso simples, que só garante que o teste roda sem quebrar em dependências externas.
  • Mock: um stub mais esperto — você verifica que o teste passou através dele, checando se ele foi chamado do jeito certo.

A confusão entre os dois é comum, e o efeito prático é usar mock onde um stub já resolveria — deixando o teste mais acoplado à implementação do que precisa.

4. Reporte o bug com contexto suficiente

  • Descrição do problema: objetiva e clara, dizendo se é sempre reproduzível ou intermitente. Exemplo: “Na tela de login, ao digitar a senha, o campo não mascara os caracteres.”
  • Criticidade: o bug te impede de continuar testando? Alta. Se não, média ou baixa, dependendo do contexto.
  • Passos pra reproduzir: passo a passo, sem pular etapa.
  • Ambiente e versão: onde aconteceu — teste, dev, produção — e em qual versão.
  • Plataforma: browser, sistema operacional, app específico.
  • Evidência: print, vídeo, log.

O mesmo princípio em dois momentos

Um teste bem desenhado — AAA aplicado com os test doubles certos — já é meio caminho andado pra quando um bug aparecer, ele ser fácil de reportar e reproduzir. Não é coincidência: as duas coisas exigem a mesma clareza sobre o que é esperado, o que foi observado, e onde exatamente a diferença apareceu.