Boas práticas, TDD, TDD

TDD simples e prático, Parte I

Fala desenvolvedores!!!

Hoje falarei um pouco sobre TDD, mas sem aprofundar no tema, apenas para plantar a sementinha da idéia.
Este é o primeiro de uma série de artigos que terão uma análise mais profunda onde resolveremos alguns problemas com TDD.

Definição simples
TDD Alexandre? O que é? TDD é o Desenvolvimento Orientado por Testes (Test Driven Development).
Isso mesmo! Desenvolvemos o nosso software baseado em testes que são escritos antes do nosso código de produção!

Se você nunca ouviu sobre TDD, ou já ouviu mas nunca tentou, sugiro ferozmente que você continue lendo o artigo e procure sobre o assunto!
A idéia do TDD já é antiga e foi firmada com o mestre Kent Beck (Autor também do famoso livro sobre TDD, que recomendo) e é um dos pilares (lê-se práticas) do Extreme Programming!

Basicamente o TDD se baseia em pequenos ciclos de repetições, onde para cada funcionalidade do sistema um teste é criado antes. Este novo teste criado inicialmente falha, já que ainda não temos a implementação da funcionalidade em questão e, em seguida, implementamos a funcionalidade para fazer o teste passar!
Simples assim!

Calma! Não tão rápido pequeno samurai! Não podemos simplesmente escrever outro teste só por que já temos um teste passando.
É preciso que esta funcionalidade que acabamos de escrever seja refatorada, ou seja, ela precisa passar por um pequeno banho de “boas práticas” de Desenvolvimento de Software.
Estas boas práticas que garantirão um software com código mais limpo, coeso e menos acoplado.

Ciclo de desenvolvimento
Red, Green, Refactor.
Ou seja:
– Escrevemos um Teste que inicialmente não passa (Red)
– Adicionamos uma nova funcionalidade do sistema
– Fazemos o Teste passar (Green)
– Refatoramos o código da nova funcionalidade (Refactoring)
– Escrevemos o próximo Teste

Ciclo do TDD

Nós temos, neste tipo de estratégia, um feedback rápido sobre a nova funcionalidade e sobre uma possível quebra de outra funcionalidade do sistema.
Assim tempos muito mais segurança para as refatorações e muito mais segurança na adição de novas funcionalidades.

Motivos para o uso
Temos diversos ganhos com esta estratégia e vou citar alguns:

– Feedback rápido sobre a nova funcionalidade e sobre as outras funcionalidades existentes no sistema
– Código mais limpo, já que escrevemos códigos simples para o teste passar
– Segurança no Refactoring pois podemos ver o que estamos ou não afetando
– Segurança na correção de bugs
– Maior produtividade já que o desenvolvedor encontra menos bugs e não desperdiça tempo com depuradores
– Código da aplicação mais flexível, já que para escrever testes temos que separar em pequenos “pedaços” o nosso código, para que sejam testáveis, ou seja, nosso código estará menos acoplado.

Mito
Muitos ainda não gostam da idéia do TDD pelo fato de termos mais código a ser desenvolvido, acarretando maior tempo no desenvolvimento de uma funcionalidade.
Mas isto está errado. Com toda certeza você desenvolvedor já corrigiu um bug no sistema, mas criou outros dois no lugar. Isto acontece com muita frequência e muitas das empresas ainda pagam os desenvolvedores somente para corrigirem bugs e até reescreverem sistemas cuja manutenção é terrível, traumática e sangrenta!

Reforçando os motivos
A médio prazo (e dependendo do sistema a curto prazo) este tempo de desenvolvimento com TDD é menor que o tempo de manutenção corrigindo bugs e mesmo para adicionar funcionalidades novas.
Isto devido, resumidamente, a:
– Confiança do desenvolvedor na correção de bugs, pois qualquer passo errado será mostrado pelos testes
– Tempo de desenvolvimento menor na adição de funcionalidades, já que o sistema é mais flexível e o código mais limpo
– Menor tempo do desenvolvedor ao corrigir bugs após aquelas incessantes brigas com o pessoal de qualidade depois da famosa frase “Mas na minha máquina funciona!”
– Possibilidde de Integração Contínua, com builds automáticos e feedbacks rápidos de problemas (assunto de um futuro post!)

Finalizando
O desenvolvedor de hoje realmente tem que dominar a técnica que, apesar de parecer nova, é desde os primórdios da civilização Inca!
O seu software funciona? Sim? Mas não tem testes? Então você não tem garantia alguma que ele funciona!

Este foi um artigo bem resumido para podermos introduzir a idéia básica do TDD e nos próximos veremos mais dicas e a criação de pequenas funcionalidades já com TDD!!

Abraços pessoal!

Advertisements

12 thoughts on “TDD simples e prático, Parte I”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s