Tempo de leitura: menos de 1 minuto
TDD (Test Driven Development) é desenvolvimento orientado por teste. Mais que testar seu código, TDD é uma filosofia, uma cultura.
Antes de entrar na Synchro, nunca tinha ouvido falar nesta técnica, se bem que antes disso, teste para mim era entrar na tela e simular o usuário fazendo uma ação, o tal do teste exploratório.
No projeto que trabalho, por ser de alta complexidade, a preocupação com a qualidade é muito grande, sendo assim já era usual escrever muitos teste. Há alguns anos, nosso arquiteto na época nos apresentou o TDD, no começo achei muito estranho “como assim, testar antes da funcionalidade estar pronta?“. Com o passar do tempo, foi ficando natural e hoje é mais tranquilo escrever o teste primeiro, principalmente usando a IDE (aqui usamos Intellij). Mesmo assim, as vezes sou vencido pela preguiça e lá estou eu testando após a funcionalidade estar pronta. Lute contra isso! kkkkk!
Vantagens
Mas qual são as vantagens do desenvolvimento orientado por teste:
- A funcionalidade já sai do “forno” testada;
- Código mais simples e com qualidade, o principal ensinamento do TDD é que se algo não é possível de ser testado então foi desenvolvido de forma errada;
- Garantia nas alterações futuras da aplicação, alterar um funcionalidade que tem teste é muito tranquilo, você tem garantias que não danificou a funcionalidade (menor índice de bugs);
- O código é separado em pequenos pedaços (baby step), e testados um passo por vez;
- Melhora o design da funcionalidade, pois ajuda no desacoplamento;
- Ajuda na documentação, ao ter testes descritivos.
Ciclo de repetição
TDD é baseado em um ciclo de repetições. Existem 3 fases:
- Red, o teste deve falhar. Escreva e execute o teste, o mesmo deve ficar vermelho, pois não tem implementação ainda.
- Green, o teste deve passar. Após implementar a funcionalidade, o teste deve ficar verde. Implemente apenas o necessário para o teste passar, lembre-se, deixe o código mais simples, assim terá qualidade.
- Refactory, refatore o código para deixa-lo mais limpo e fácil de entender, já que não existirá documentação, isso provavelmente deixará o teste vermelho novamente e o ciclo reinicia.
Lembre-se: Se você está fazendo um teste para um código existente, você não está fazendo TDD.
Como Implementar
Nenhuma biblioteca especial é necessária para implementação do TDD, pois como já disse TDD é uma técnica. No Java usamos o JUnit mesmo, que é uma biblioteca para testes unitários.
Mas por onde começar?
- Entenda o problema proposto;
- Identifique as entradas e saídas;
- Escreva os cenários de teste.
- Escreva e execute o teste.
- Implemente a funcionalidade.
- Refatore se necessário.
Exercitando…
Passo 1: Entender o problema
- Construa uma calculadora com as operações soma e subtração.
Nota: Aqui temos dois problemas, nossa calculadora deve somar e subtrair.
Passo 2: As entradas e saídas para os dois métodos são as mesmas:
- Entrada: dois números (vamos usar inteiro, para não complicar o exemplo)
- Saída: um número.
Passo 3: Escreva os cenários
- Cenário 1: a soma de 1 + 2 deve retornar 3.
- Cenário 2: a soma de 0 + 0 deve retornar 0.
- Cenário 3: a subtração de 5 – 2 deve retornar 3.
- Cenário 3: a subtração de 5 – 6 deve retornar -1.
Passo 4: Escreva e execute o teste
Lembra-se: O nome do teste deve ser o mais explicativo possível, o tamanho do nome do teste não é importante.
[code language=”java”]
@Test
public void testeSomaUmComDoisERetornaTres(){
CalculadoraService calculadora = new CalculadoraService();
Integer resultado = calculadora.somar(1, 2);
Assert.assertTrue(3 == resultado);
}
[/code]
No exemplo a cima o serviço “somar” da classe CalculadoraService ainda não foi implementado, sendo assim, quando executar esse teste, a falha é esperada.
Passo 5: Implemente a funcionalidade
Após a constatação da falha, partimos para implementação do método “somar”.
[code language=”java”]
public Integer somar(final int valor1, final int valor2) {
final int resultado = valor1 + valor2;
return resultado;
}
[/code]
Pós implementação, execute o teste novamente, desta vez é esperado que o teste passe, fique verde. Caso ocorra do teste falhar, grande possibilidade da sua implementação estar errada, não o teste.
Passo 6: Refatore se necessário.
No exemplo que usamos, o método é bem simples, a única refatoração que cabe é fazer a operação in line, diminuindo assim a complexidade do método.
[code language=”java”]
public Integer somar(final int valor1, final int valor2) {
return valor1 + valor2;
}
[/code]
Após refatoração, execute o teste novamente, se antes de refatorar o seu teste estava verde, o resultado por refatoração deve permanecer verde, caso contrário, refatore o novamente.
Conclusão
TDD agregou muito na minha vida de programador, o pensar simples faz toda diferença ao fim de uma atividade. O entendimento e a leitura do código fica fluida, ajuda muito no código limpo e na documentação, pois em alguns casos, ao ler os cenários é possível entender a funcionalidade.
Deixo aqui algumas referências sobre o tema. E pratique, só assim o conceito é incorporado!
Aproveito para lembrar novamente do CodeKata #3: Restaurante, quinta-feira (17/03) é o ultimo dia para enviar a solução.
Abraços.
