Postagem em destaque

Procurando Profissional em Análise de Processos de Negócios, BPM, BPMS e Melhoria de Processos, para atuar na Região Metropolitana de Belo Horizonte?

Marco Gandra Brasileiro – Casado 41 anos - CNH B Nascido em Belo Horizonte e-mail gandraribeiro@gmail.com ...

Pesquisar neste blog

30 de mai de 2012

Princípios de Test Driven Development (TDD)

Por: Camilo Lopes
Em: http://imasters.com.br/artigo/24242/desenvolvimento/principios-de-test-driven-development-tdd


Olá, pessoal! No artigo de hoje eu vou apresentar alguns princípios importantes sobre TDD - tudo com base no conhecimento e experiência que venho adquirindo desde de 2010. Espero que gostem e que o artigo ajude vocês!
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 funcione como deveria.
Na pratica, quando você termina os testes, terminou o desenvolvimento principal e está seguro que aquela classe faz o que se espera dela - claro que terá que fazer teste de integração, mas aí é outra historia.

A crença do iniciante

Todo mundo que inicia com TDD, no inicio fala:
“Meu Deus, que coisa mais chata e ainda dá mais trabalho. Pra quê eu vou criar uma nova classe com métodos, 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 quando fomos apresentados. Um dos pontos era esse: a impressão de que ele dá mais trabalho, por escrever os métodos testes (unit tests). Isso era algo que eu não conseguia entender.
O segundo ponto era pensar nos testes e no fato deles serem específicos para cada situação. Isso 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 como done.

Superação

Com persistência e coragem, eu fui me adaptando ao “novo ambiente”. É normal termos resistência ao que é novo e o que me motivo a superá-la foi o fato do mercado usa o TDD e os  experts (Martin Fowler, Kent Beck, Guilherme Silveira, Rodrigo Yoshima, etc) de TI defendem o uso. Então, por que eu não devo usar? Será que eles também não tiveram os mesmos problemas no começo? E a partir disso eu fui em frente e virei um viciado em TDD. Não consigo mais fazer uma aplicação, por mais simples que seja, sem TDD. É muito bom ver o sinal “vermelho” e o “verde” - um dizendo que preciso consertar alguma coisa e outro dizendo que o meu o meu conserto foi aprovado.

Antes de TDD

Antes de TDD, eu achava que entregava um programa da maneira como ele tinha sido solicitado, mas não durava muito tempo e o pessoal de QA me mandava todos os bugs que apareceram - 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 me lembro é que o usuário esperava que uma determinada ação ia retornar o CPF - e eu acreditei que o método retornaria de fato -, mas na verdade, vinha um null e quando fui ver, eu tinha esquecido em algum lugar de passar o valor de um atributo do objeto para o método responsável.
Com o TDD, isso ainda pode acontecer. A diferença é que o risco diminui. Quando entregamos algo com TDD, estamos seguros de 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. 

Os princípios fundamentais que devemos ter ao adotar TDD

  • escrever o TESTE da implementação ANTES de escrever code core;
  • escrever apenas o código suficiente para o teste e se contentar com isso (controle sua ansiedade);
  • escrever teste pequenos, testando a menor quantidade possível de código de cada vez;
  • escrever testes rápidos (não é programar rápido e sim testes que rodem rápido, em milisegundos).

O ciclo de vida TDD

  1. criar o teste;
  2. executar todos os possíveis testes e ver a aplicação falhar (barra vermelha no junit);
  3. escrever a 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 (princípio de refactoring).

Por que adotar?

  • necessidade de manter compatibilidade retroativa;
  • baixa cobertura de testes unitários;
  • design pouco testável.

Tipos de testes

  • Testes unitários - testam apenas um componente do sistema:
  1. ferramentas: Junit, Jmock
  2. fundamental para prática do TDD
  • Testes de integração - testam integração entre componentes que envolvem dois ou mais. Ex.: classes + SGBD
  1. ferramentas: Junit, DBUnit
  • Teste de aceitação - testam uma funcionalidade, ou caso de uso e envolve vários componentes do sistema.
  1. 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 unitários (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, às vezes, assustado como essas pessoas não sabem fazer interpretação. Não está escrito em lugar nenhum que o TDD, Scrum, ou XP são bala de prata. Porém, eles deduzem isso. Hoje, particularmente, não discuto mais sobre o assunto com essas pessoas; simplesmente ignoro a discussão (e não a pessoa).
Mas, por que faço isso? Antes (não foi há muito tempo), eu até tentava discutir (normal entre profissionais de TI) e mostrar que não é isso que os Agilistas têm 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 vão dar em lugar nenhum.
Quem desenvolve com TDD sabe que é possível desenvolver com zero bugs ou algo próximo disso; e quando um bug é 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 e o quanto custa consertar um bug.
E qual o nível desse bug? Você já precisou parar um sprint por causa de bugs? Então, você tem um problema sério na qualidade de desenvolvimento do seu produto, pois ele bloqueou todo o ciclo do produto.
Claro que estou falando de TDD a nível de código, pois é onde temos o uso da pratica mais desenvolvido e com cases e mais cases de diferentes companhias.

Conclusões

  • colabora para o aumento da qualidade dos sistemas;
  • o software cresce de forma ordenada e com qualidade de design;
  • o software se adapta com mais facilidade a mudanças.   

Nenhum comentário:

Postar um comentário