Testes automatizados
Se você não está convencido de que os testes automatizados são um recurso valioso para sua estratégia de desenvolvimento de software, esta publicação não é para você. De agora em diante, vamos considerar que você não apenas sabe o que é, os tipos de testes automatizados existentes, mas também vê valor neles.
Quando falamos em escrever testes de código, há armadilhas que precisam ser consideradas. O código que você cria para executar os testes também é código. Isso pode parecer óbvio, mas quantas vezes você já pensou em procurar Test Smells em seu código? Quanto mais você codificar os testes, mais esforço terá para mantê-los.
Então, se houver uma troca aqui, o que devo fazer?
Como podemos ver acima, a maior compensação é equilibrar a quantidade de testes em relação ao custo de tê-los, e a pirâmide acima expressa o que achamos que você deve fazer.
Os testes unitários são baratos, você pode ter muitos deles, são rápidos de escrever (existem até ferramentas de IA que os geram para você hoje em dia), rápidos de executar e validam o comportamento do seu código. Além disso, escrever testes unitários o ajudará a criar melhores abstrações e a seguir os princípios SOLID.
Os testes de contrato o ajudarão a garantir que a interoperabilidade esteja intacta. Tudo o que fazemos hoje em dia envolve algum tipo de integração. Essa é uma estratégia de teste valiosa. Isso também significa que sua execução será mais cara. Recomendamos que você codifique testes de contrato para as partes do software que interagem com um agente de terceiros, como outros sistemas externos. Dessa forma, você escreverá menos código e testará o que vale a pena testar.
Os testes de integração são mais complexos de escrever e manter. Você não precisa testar apenas o seu código, mas também as partes às quais ele se conecta. Às vezes, provisionar a infraestrutura na memória para permitir que o teste seja executado é uma saída, mas, às vezes, você terá de contar com uma infraestrutura em funcionamento para executá-los. Recomendamos que você escreva esses testes apenas para os principais recursos do sistema.
Os testes E2E (ponta a ponta) levam muito tempo para serem implementados e ainda mais para serem mantidos. A precisão e a confiabilidade, por outro lado, são incríveis, pois você estará realmente fazendo o que o usuário deseja. Escolha apenas o caminho crítico do seu software, o que precisa ser executado para ser útil aos seus usuários e somente isso.
Se estiver procurando um número mágico para a cobertura de código, é muito difícil defini-lo para cada cenário, mas 80% parece ser um número razoável para a maioria dos cenários. Se isso for bem distribuído, você estará executando uma boa maneira de garantir a qualidade do seu software.