O único tipo de teste que escrevo

Há uma conversa de fundo quase constante no mundo da engenharia sobre quais tipos de testes são melhores; testes de unidade, testes de integração, testes de ponta a ponta e assim por diante.

Há algum tempo, decidi que escreveria apenas um tipo de teste.

Não tenho certeza se ele se encaixa perfeitamente em qualquer uma das categorias acima. Talvez 'teste de integração' seja o mais correto, mas isso não o cobre totalmente - até porque ninguém pode realmente concordar sobre como realmente definir o que esses rótulos diferentes significam.

Aqui estão os princípios que sigo:

1. Não escrevo um único teste até ter uma interface pública clara definida.
2. Meus testes devem emular o mais próximo possível o comportamento de um usuário real . Isso significa chamar apenas APIs públicas ou, se for uma interface de front-end projetada para um usuário final, fazer apenas o que um usuário final faria.
3. Se uma função ou componente não faz parte da interface pública, não a testo diretamente. Se não for possível invocá-lo indiretamente por meio de algum caminho público, qual é exatamente o seu propósito?
4. Nenhuma chamada de rede remota. Se não for uma chamada para localhost (por exemplo, um banco de dados de teste local), ele precisa ser simulado. Meus testes devem passar consistentemente sem rede ou conexão com a Internet.
5. Sem zombar de caminhos de código interno. Zombar no limite da rede é ótimo, mas zombar de funções ou APIs que existem dentro da base de código que estou testando é impossível.
6. Nenhum estado realizado em diferentes testes. Se um teste depende do estado de um teste anterior ou pode ser afetado por esse estado de alguma forma, algo deu errado. Isso não significa 'limpar todos os estados após cada teste'.
7. Nenhum teste de estado interno. Se eu tiver que inicializar ou ajustar algum estado interno manualmente em meu teste (sem usar outra interface pública existente), meu teste provavelmente não será bom.
8. Nenhum teste de detalhes de implementação interna. Se refatorar meu código fará com que o teste falhe, provavelmente não é um bom teste.
9. Nenhum 'teste de unidade' que invoca funções internas. Se eu sentir o forte desejo de testar funções como esta, elas provavelmente devem ser divididas em seu próprio módulo ou pacote autônomo de antemão, com uma interface clara que é completamente desacoplada de qualquer lógica de negócios.
10. Nenhum teste de estilo 'ponta-a-ponta' que requer a criação de um servidor completo e banco de dados e vários serviços e execução de todos juntos, a menos que seja extremamente conveniente fazer isso em meu host local.
11. Concentro-me na 'cobertura de casos de uso' em vez da 'cobertura de linhas de código'.
12. Escreva um teste primeiro se estiver muito claro com antecedência como será a aparência da interface pública. Caso contrário, escreva o código primeiro e depois teste-o.
13. Eu quebro qualquer uma das regras acima quando é melhor fazê-lo do que não escrever um teste ou deixar um caso de uso não testado.