[quote=Andre Brito]Estou a estudar TDD a algum tempo e sempre vejo nos exemplos algumas coisas bem simples. Gostaria de saber se no ‘mundo real’ dos desenvolvedores acontece da mesma forma.
Por exemplo, depois de meus estudos, fui fazer uma calculadora usando um TDD (me aparenta ser um exemplo bem simples).
Eu teria a classe TestCalculator com alguns testes ali. O primeiro, seria testar a soma de 1 + 2, por exemplo. Na minha classe Calculator eu teria um método add, retornando um inteiro e recebendo dois. Eu retornaria 3, porque devo só passar aquele teste escrito.
Mesmo sabendo que pra outro teste (2 + 2) não passará, devo eu manter essa simplicidade e “inocência” de não escrever o método pra retornar a soma dos dois parâmetros? Digo, devo eu não codificar um return x + y (logo na primeira vez que escreverei o método) sabendo que se continuar retornando 3 dará errado? Eu sei que terei de refatorar no futuro, mas isso não toma tempo do desenvolvedor? Ou de outra forma, deveria eu não escrever um método de soma genérico já de primeira?
Creio que não escrevi minha dúvida de forma correta, mas se entenderem, gostaria de saber a opinião de vocês.[/quote]
Voce sem querer citou 3 abordagens que o Kent Beck descreve no livro de TDD (faking, triangulation e obvious solution). Todas elas fazem sentido no mundo real, mas sao dificeis de se entender com problemas simples como da calculadora.
Com faking, voce retorna o valor esperado e passa para o proximo teste (que deveria testar outra parte do contrato do seu metodo). Isso eh bom para ganhar tempo para pensar nas outras responsabilidades do metodo antes de partir para a implementacao final. No seu exemplo, significaria retornar 3 e partir para um teste com numeros negativos, ou de ponto flutuantes, e so depois disso implementar a solucao, que pode acabar nao sendo um simples +.
Ja na triangulacao, voce cria um segundo teste para sair da implementacao fake rapidamente. Isso eh bom para descrever com mais detalhes o metodo sendo implementado, quando isso eh necessario. No caso da soma, isso dificilmente seria preciso. (a maneira mais facil de se chegar a solucao seria pela eliminacao de duplicidade - a constante 3, sendo utilizada tanto no teste quanto no codigo)
E para os casos simples como da soma, voce pode partir para a solucao obvia. Nao ha motivo para escrever mais codigo se a solucao eh clara e bem descrita no teste. Isso eh facil de se julgar no caso da calculadora, mas na “vida real” eh preciso ser um pouco mais cuidadoso antes de usar esta abordagem.
Eh normal estranhar alguns aspectos do TDD, principalmente quando esta praticando. O que eu sugiro eh que depois da calculadora voce parta para um problema cuja solucao nao seja tao obvia e tente aplicar as 3 abordagens para sentir a diferenca entre elas. Saber quando e como usar cada uma delas eh o que vai realmente ser util no “mundo real” 