Deixa eu te perguntar: quantos cenários de testes você enxerga no código abaixo:
/** * Registrar novo lance no leilão */ public void darLance(Lance lance) { if (lance.getValor() <= 0) throw new RuntimeException("Lance com valor negativo"); this.lances.add(lance); }
E aí, quantos? 1, 2 ou 3 casos de teste? Não é tão simples assim não, é mesmo?
Um especialista de Q&A responderia facilmente, afinal ele estudou muito para isso! Mas nós desenvolvedores temos maior dificuldade, precisamos de experiência para identificar cenários em código e muitas vezes até ferramentas de cobertura de código:
Não identificar fluxos de negócio em um trecho de código pode trazer diversos bugs para o sistema. Não é por acaso, como testar algo que não conseguimos enxergar?
Não dá né…
Um boa maneira de melhorar sua percepção é escrevendo testes automatizados. Escrever testes aumenta nossa percepção a um nível surpreendente.
Para te ajudar a entender toda a problemática, acabamos de blogar sobre o assunto e porque você deveria se preocupar com os fluxos alternativos do seu código:
[Post] jUnit: testando fluxos de exceção e erro
Cobrir fluxos alternativos e excepcionais com testes é muito barato se comparado a testes manuais. Você nem vai precisar levantar seu Tomcat outra vez…
PS: e aí, quantos cenários você encontrou? Comenta aí embaixo, vamos bater uma bola…
Nossa tô mal identifiquei apenas 2, lance poderia vir null e valor igual a 0.