Dê o próximo passo e inicie sua carreira
Dê o próximo passo e inicie sua carreira agora mesmo
3 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Testes automatizados são muito importantes. Quando bem feitos e em número suficiente, passamos a ter uma garantia de que nosso código faz o que deve (e continua fazendo depois de alterações).
Além disso, há uma forte influência na direção de uma boa modelagem, ainda mais quando usamos . Ao aplicarmos o ciclo de do TDD, passamos menos tempo debugando e encontramos bugs o mais cedo o possível.
Porém, para colhermos as vantagens dessas técnicas, precisamos lembrar de executar nossa suíte de testes DEPOIS DE QUALQUER ALTERAÇÃO. Esperarmos até o servidor de integração contínua avisar-nos é tarde demais. E como costumamos dizer aqui na Caelum: se o programador precisar de lembrar, pode ter certeza que ele vai esquecer.
Quando demoramos para executar nossos testes, mais erros podem acumular-se. Ao descobrirmos as falhas nos testes, o contexto do que estávamos fazendo não estará mais tão claro. É provável que passemos mais tempo debugando e "caçando" a raiz dos defeitos.
Para evitar que o programador precise lembrar de executar a suíte de testes sempre que alterar algum código, foram criadas as ferramentas de teste contínuo. Apenas aqueles testes que foram afetados pelo código modificado serão executados, de maneira a minimizar o tempo de execução dos testes. Em Ruby há ferramentas como o watchr, em Python temos o sniffer e em Java temos o Infinitest.
O Infinitest tem plugins para o Eclipse e IntelliJ. Observe a execução em um projeto no Eclipse:
Perceba que ao alterar a classe GeradorDeRecibo, somando 1 ao total, o canto inferior da tela passa a ficar vermelho, sinalizando que algum teste quebrou. É exibido também o número de testes executados (1 test cases ran). Só um teste foi executado, apesar de existirem outros no projeto.
A classe GeradorDeReciboTest é marcada com um erro exatamente na linha onde ocorreu a falha no teste. O detalhe do erro mostra que era esperado um 2.0 como total, mas veio 3.0.
Logo a recompilação do código pelo Eclipse, o Infinitest analisa as mudanças e executa apenas os testes afetados. Porém, existem diferentes níveis de testes: unidade, integração e sistema. Testes de unidade são rápidos: uma suíte completa é executada em alguns segundos. Já os de integração e sistema são mais lentos, porque acabam testando mais coisas.
Por isso, é ideal configurar o Infinitest para executar apenas os testes de unidade. Para isso, crie um arquivo infinitest.filters na raiz do seu projeto e coloque expressões regulares que peguem o nome das classes que você quer excluir.
Por exemplo, se você quiser excluir todos os testes de DAOs, exclua o pacote com: br\.com\.caelum\.dao\..*.
Se desejar excluir todas as classes terminadas com ITest (padrão usado pelo plugin failsafe do Maven), coloque: .*ITest.
Ao criar novos testes (e novas funcionalidades), tenho a tendência a ignorar os testes vermelhos. Talvez o ideal seja deixar seus testes quebrados o mínimo possível. Mas confesso que não tenho essa disciplina.
Agora, ao refatorar, seus testes nunca deveriam quebrar. Tudo deve ficar sempre verde. Nesses casos, executar continuamente seus testes de unidade vale muito a pena!
Avalie este artigo
