Projete o software para ser testável. Um bom software precisa ser fácil de testar. Comunique a intenção do teste. Testes precisam ser fáceis de ent...

Projete o software para ser testável. Um bom software precisa ser fácil de testar. Comunique a intenção do teste. Testes precisam ser fáceis de entender e de manter (não se esqueça de que temos que fazer manutenção também dos testes ao fazer uma mudança no software). Por isso é importante que os nomes dos testes mostrem claramente a intenção do teste. Não modifique o sistema para testar. Um erro bastante comum de testadores iniciantes é alterar o código “só para realizar os testes” – como, por exemplo, inicializar uma variável com um valor especial para facilitar o teste. Essa mudança pode fazer com que o teste deixe de ser automático (tornando-se semiautomático) – já que é preciso alterar alguma parte do código antes de testar. O pior é que podemos esquecer de alterar o código para o valor correto após executar os testes! Ou seja, ao testar, podemos introduzir um defeito. Um outro erro bastante comum é abrir brechas na classe para facilitar os testes (um exemplo simples: criar um método auxiliar na classe só para ser usado para o teste). Porém, essas brechas podem ser usadas por desenvolvedores desavisados ou mesmo por alguém mal-intencionado. Note que o princípio “projete o software para ser testável” não é contraditório com esse princípio: um software bem projetado para testes não tem brechas! Mantenha os testes independentes. Um teste não deve depender do resultado de um outro teste. Se houver dependência, vários testes podem não passar ao mesmo tempo por um único motivo, o que dificulta a identificação do defeito. Isole a unidade sendo testada. Se o teste envolver uma outra unidade, um defeito nela pode propagar para a unidade sendo testada – por mais que a unidade sendo testada esteja correta. Por isso deve-se isolar a classe e o método sendo testado. Pensando em classes, é normal que haja dependência entre classes; veremos mais adiante como lidar com isso.