Test-Driven Development

Filosofia

Princípio central: Testes devem verificar comportamento através de interfaces públicas, não detalhes de implementação. O código pode mudar inteiramente; os testes não devem.

Bons testes são integration-style: exercitam caminhos de código reais através de APIs públicas. Descrevem o que o sistema faz, não como. Um bom teste lê como uma especificação — "user can checkout with valid cart" te diz exatamente qual capacidade existe. Esses testes sobrevivem a refactors porque não se importam com estrutura interna.

Testes ruins são acoplados à implementação. Mockam colaboradores internos, testam métodos privados ou verificam por meios externos (tipo fazer query direto no database em vez de usar a interface). Sinal de alerta: seu teste quebra quando você refatora, mas o comportamento não mudou. Se você renomeia uma função interna e testes quebram, esses testes estavam testando implementação, não comportamento.

Veja tests.md para exemplos e mocking.md para diretrizes de mocking.

Anti-Pattern: Horizontal Slices

NÃO escreva todos os testes primeiro, depois toda a implementação. Isso é "horizontal slicing" — tratar RED como "escrever todos os testes" e GREEN como "escrever todo o código".

Isso produz testes ruins: