Que tipo de teste escrever para reduzir o custo total de um projeto de software

Projetos com testes automatizados bem feitos são mais baratos de desenvolver e manter. Entretanto, é interessante que, mesmo com esta constatação, ainda é comum encontrar projetos “sem testes automatizados” ou, o que pode ser até pior, com testes que não reduzem o custo total. Além disso, ainda mais comuns são projetos com distribuição não balanceada de tipos de testes.

Como profissionais, é nosso trabalho desenvolver testes de qualidade que reduzem os custos do software, melhorando eficiência e confiança.

Testes de tipos diferentes podem ter custos significativamente diferentes. Definir a quantidade de testes automatizados, de cada tipo, necessários em uma aplicação é uma atividade complexa. Uma das abordagens mais familiares foi recomendada, em 2012, por Martin Fowler: trata-se da pirâmide de testes, criada por Mike Cohn.

Segundo a pirâmide, em uma distribuição saudável, a maioria dos testes da base devem ser testes automatizados, que custam menos e são mais rápidos para executar. Entretanto, também são importantes testes de integração e testes end to end.

Quando precisamos evoluir sistemas com poucos ou sem nenhum teste, é intuitivo começar pela base da pirâmide, ou seja, com testes de unidade por apresentarem melhor relação de custo e benefício. Entretanto, para sistemas e times legados, onde o domínio não está devidamente codificado ou o time tem pouca experiência, geralmente é mais efetivo adotar testes de aceitação, implementados end-to-end ou integração, inicialmente. Obviamente, atentando, sempre, para o fato de que, se dependências externas não forem isoladas, execuções serão mais lentas e potencialmente mais caras.

Sabemos que code coverage baixo indica problemas. Entretanto, também sabemos que code coverage alto não indica que as partes importantes do código estão sendo testadas adequadamente. Conforme o princípio de Pareto, sabemos que 20% das funcionalidades representam 80% do uso de um software, logo, estas funcionalidades devem receber mais testes.

No longo prazo, a distribuição indicada pela pirâmide de testes parece ser a ideal e é bom indicativo de como planejarmos a evolução dos projetos.

Se um homem não sabe a que porto se dirige, nenhum vento lhe será favorável – Sêneca

Em Resumo
  • O problema

    Em sistemas e times legados, onde o domínio não está devidamente codificado ou o time tem pouca experiência, é difícil escrever testes de unidade. Além disso, é fácil escrever, mesmo em cenários melhores, testes que não adicionam valor para o negócio.
  • O insight

    A pirâmide de testes, criada por Mike Cohn e popularizada por Martin Fowler, serve como ótimo guia para sabermos se estamos escrevendo os tipos de testes necessários para reduzir os custos de uma aplicação. Entretanto, para sistemas e times legados, onde o domínio não está devidamente codificado ou o time tem pouca experiência, geralmente é mais efetivo adotar testes de aceitação, implementados como end-to-end ou integração, inicialmente.

Rafael Amaral

Atuo na área de desenvolvimento de software como programador e tech leader. Meus principais interesses são Arquitetura, Code Quality, Liderança e Agile. Alem disso, gosto de Literatura, Filosofia e Finanças ... E tudo isto banhado com muito Metal.

Talvez você goste também

Carregando posts…

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *