olá Pessoal,
Esse post está preparado desde de 2010, porém vinha postergando, por falta de tempo para organizá-lo. Mas felizmente chegou o dia. O objetivo que estarei compartilhando a minha experiência que venho tendo com TDD há pouco mais de um ano e confesso que cada vez que preciso fazer um novo código eu vejo que mais preciso aprender a criar meus unit tests. É inacreditável como TDD é algo bem dinâmico, a ação sempre é a mesma de escrever os testes primeiro, mas cada teste sempre traz um desafio. E isso é um estimulante dos fortes. Eu adoro isso. Sem falar que com TDD nos força a se envolver mais e mais na área de negócios, pois quanto mais entendemos mais fácil fica escrever os testes. vou apresentar alguns princípios básicos sobre TDD para quem está querendo fazer sua primeria app Java com TDD e em outro post, vamos colocar mão na massa.
Outra novidade que a partir de hoje, estarei dando inicio à série de post Agile com base em experiências e estudos que venho adquirindo nessa longa jornada que terei com Agile. E espero através do blog ir compartilhando isso com vocês, uma vez que que venho advogando Agile no desenvolvimento de Software ultimamente.Além deste ser é um dos objetivos na minha carreira. Além, disso quero poder ajudar os iniciantes que tem dúvidas sobre o mundo Agile, sem falar na quantidade de siglas que no inicio é um pouco confuso para os iniciantes: TDD, Scrum, XP, DDD etc.Eu tive dificuldades, barreiras (não é que agora não tenho mais, porém são outras rs, aprendizado é base de Agile)e tentar ensinar alguma coisa para quem está precisando só de um empurrãozinho para vim fazer parte do Agile Team é algo que sempre gostei de fazer aqui no blog e não será diferente com Agile.
Espero que gostem . 🙂
Lets go…
Outros Post:
Starting…
No TDD você desenvolve os testes do software antes mesmo de desenvolver o software(eu chamo de code core). Para cada “peça” da aplicação que é construída uma série de testes são escritos ANTES do desenvolvimento para garantir que a aplicação funciona como deveria funcionar.
Na pratica, quando você termina os testes, terminou o desenvolvimento principal e está seguro que aquela classe faz o que se espera.
A crença do iniciante
Todo mundo que inicia com TDD, nos primeiros passos fala:
“meu deus, que coisa mais chata e ainda dar mais trabalho, pra que diabos eu vou criar uma nova classe com metodos, se eu poderia fazer um método único( main) com todos os possíveis erros e ver no console o resultado com System.out.println!?”
Bem, eu devo confessar que pensei assim também, pois tive resistência ao uso TDD logo quando fui apresentado ao sr. TDD Master. Um dos pontos era esse:a impressão que dar mais trabalho escrevendo os métodos testes(unit tests).Isso era algo que eu não conseguia entender.
O ponto 2 era pensar nos testes e que eles fossem especificos para cada situação, era outro ponto difícil, pois não conseguia pensar que tipo de case criar, uma vez que não tinha o código core pronto.
Superação
Com persistência e coragem fui superando o “novo ambiente”, é normal termos resistência ao que é novo, e o que motivou foi o seguinte ponto: “o mercado usa, os caras mais punks(Martin Fowler, Kent Beck, Guilherme Silveira, Paulo Silveira, Rodrigo Yoshima etc) defendem o uso, e põe em pratica, e porque eu não devo usar?Eu estou errado ou o mundo está errado? Será que eles também não tiveram os mesmos problemas?”. E daí fui em frente e virei um TDD-Viciado, não consigo mais fazer uma aplicação por mais simples que seja sem TDD, é muito bom ver o sinal de “Vermelho” e “Verde”, um dizendo que preciso fix algo e outro dizendo que o meu fix foi aprovado. E o mais divertido quando uma regra de negócio muda, quebram algum teste e aí eu sei: “mudaram o código, que regra mudou?”.
Antes de TDD
Antes de TDD, eu achava que tinha entregue um programa como foi solicitado, mas não durava muito tempo lá vinha a pilha de bugs pelo pessoal de QA, e a maioria era em algo que não implementei, ou que achei que estaria funcionando corretamente, mas na verdade não estava. Um exemplo, prático que lembro no projeto do ano passado é que o usuário esperava a partir de ação receber o CPF e acreditei que o método retornaria de fato este valor para ele, mas na verdade vinha um null e quando fui ver em algum lugar lá esqueci de passar o valor de um atributo do objeto para o método responsável.A moral aqui que para saber, tive que debugar, e isso consome tempo.
Com TDD isso ainda pode acontecer, a diferença é que o objetivo é diminuir esse risco, de quando entregarmos algo com TDD estamos seguro que estamos entregando a coisa certa com o risco menor. O problema na minha época pré-TDD é que o tempo de manutenção não era tão curto como esperado, pois eu não sabia onde estava o erro e tinha que usar o debug do eclipse até encontrar. Li em algum lugar que o “debug” deveria ser removido do Eclipse para alguns projetos. Só não lembro quem falou isso agora. hehe.
Os princípios fundamentais que devemos ter ao adotar TDD :
– escrever TESTE da implementação ANTES de escrever code core;
– escrever apenas código suficiente para o TESTE possa se contentar com isso(controle sua anciedade);
– escrever TESTE pequenos, testando a menor quantidade possível de código de cada vez;
– escrever TESTE rápidos(não é programar rápido e sim tests que rodem rápido, em milisegundos).
O ciclo de vida TDD(veja a imagem no inicio do post)
1.criar o teste
2.executar todos os possíveis testes e ver aplicação falhar(barra vermelha no junit);
3.escrever aplicação a ser testada;
4.executar os testes para ver se todos passarão;
5.Refatorar – refactoring;
6.executar os testes novamente e garantir que eles continuem passando(principio de refactoring)
Pq adotar?
- necessidade de manter compatibilidade retroativa;
- baixa cobertura de testes unitários;
- design pouco testável
Tipos de Testes
Teste unitarios
testam apenas um componente do sistema.
- Ferramentas: Junit, Jmock
- Fundamental para prática do TDD
Testes de Integração
testam integração entre componentes que envolve dois ou mais. Ex.: classes + SGBD
Ferramentas: Junit, DBUnit
Teste de Aceitação:testam uma funcionalidade ou caso de uso e envolve vários componentes do sistema.
Ferramentas: Junit, Selenium
Pode ser usado em TDD
Consequências
- testes podem ser feito na IDE
- Não há necessidade de fazer um deploy da aplicação para execução dos testes ;
- bugs são encontrados com mais facilidade e corrigidos com maior velocidade;
- bugs comprovados por testes unitarios (barra vermelha na tela);
- código mais estável, pois estimula um melhor design;
- facilita a técnica de refactoring;
- evitar o “overdesign”, ou seja, só escrever código suficiente para o teste passar ;
Pontos de Reflexão
Há pessoas que são contra ao uso de TDD, Agile etc. Dizem que isso é coisa de “pensadores” e que não existe “bala de prata”. Mas, eu não sei de onde vem o “bala de prata” e fico as vezes assustado como essas pessoas não sabem fazer interpretação. Não há lugar nenhum escrito que TDD, Scrum, XP são bala de prata. Porém, essas pessoas deduzem isso. Hoje particularmente não discuto mais sobre o assunto com essas pessoas, simplesmente ignoro a discussão (e não à pessoa 🙂 ).
Mas, por que faço isso?
Antes, eu até tentava discutir (normal entre profissionais de TI) e mostrar que não é isso que os Agilistas tem em mente, mas era difícil e tentar mudar as pessoas é algo praticamente impossível. E um dos princípios que incorporei como Agilista foi “aprendizado” e tive que aprender, que não podemos mudar as pessoas.Depois disso vivo mais feliz, com menos discussões que não terão resultado no final.
Outro problema os bugs
Quem desenvolve com TDD sabemos que é possível desenvolver com zero bugs ou algo próximo de zero, e quando é encontrado o custo de manutenção é relativamente baixo com relação ao que já conhecemos no dia-dia. Porém, você vai encontrar alguém dizendo por ai: “Bugs fazem parte do desenvolvimento de sistemas, todo sistema tem bugs”. De novo, não estamos dizendo que um sistema não tem bug, o problema maior não é ter, e sim como resolver, daí eu pergunto quanto custa fixar um bug?
E qual o nível desse bug ou bugs?
Você já precisou parar um Sprint por causa de bugs?(a resposta para o Sim, vem logo adiante)
Então você tem um problema sério na qualidade de como o seu produto foi desenvolvido. Se você tem uma pilha de bug, que impacta o desenvolvimento, então a coisa é muito séria concorda? Pois, bloqueou todo o ciclo do produto.
Conclusões
- colabora para o aumento da qualidade dos sistemas;
- software cresce de forma ordenada e com qualidade design ;
- software se adapta com mais facilidade à mudanças ;
- Ninguém falou que Agile é a bala de prata;
Vou ficando por aqui, e espero que tenham gostado do post.
abracos see ya!