Código limpo e auto-explicativo! Este é o objetivo do Test Driven Development ou TDD. O TDD é composto por práticas propostas pelo eXtreme Programming, reforçando os conceitos de Design Evolutivo e Test First. Focado nestes dois conceitos, tentarei explicar quais os benefícios de uma abordagem baseada no TDD.
Algo que tenho visto freqüentemente em clientes e treinamentos por todo o Brasil é que, em se tratando de processos de desenvolvimento Ágil, os desenvolvedores ficam um pouco perdidos no início do projeto. Isso deve-se ao fato de que a prática tão falada de desenvolvimento incremental gera várias dúvidas sobre a integridade e arquitetura do sistema. Os desenvolvedores simplesmente não sabem qual componente usar, quando usar e principalmente se é necessário usar. Isso já era de se esperar, pois estávamos acostumados ao modelo tradicional, onde esse tipo de decisão era responsabilidade de um arquiteto e nós apenas obedecíamos.
Para facilitar o desenvolvimento incremental, uma das soluções é aplicar o design evolutivo. Design evolutivo significa que você só deve se preocupar com o design relativo à funcionalidade que está em sua mão naquele momento, porém deixar pontos de extensão para facilitar o a evolução. Esse tipo de prática favorece o refactoring e garante flexibilidade quando o cliente decide mudar o escopo da aplicação.

Os desenvolvedores habituados ao modelo tradicional de desenvolvimento de software não estão habituados ao design evolutivo. Não estão acostumados a tomar decisões de design a cada funcionalidade que precisam implementar. Isso gera um desconforto e receio na hora de implementar a solução. O TDD ajuda nessa questão. Permite que o desenvolvedor se veja como um consumidor daquela funcionalidade, pois é obrigado a refletir sobre o código que irá escrever, pensando em como seria sua utilização.
Para que isso seja realidade, é necessário utilizar também a prática conhecida como Test First. Essa prática consiste em escrever o teste antes de escrever o código real, obrigando que o desenvolvedor imagine o código real antes mesmo de começar a escrever. Dentre outras coisas, isso também ajuda a ativar o lado criativo do cérebro, pelo fato de exigir o uso da imaginação. Isso muitas vezes revela-se o maior desafio para os iniciantes dessa abordagem, porém conforme o avanço no desenvolvimento isso se torna natural para o desenvolvedor, aumentando em muito a qualidade do código. Isso reforça também a idéia de que desenvolver software é uma arte e deve ser realizada por artesãos de software.
A pergunta mais freqüente que ouço sobre isso é referente ao retrabalho que isso pode causar e o impacto gerado por grandes mudanças no escopo. Como resposta, pergunto: Qual seria o impacto desse tipo de mudança em uma arquitetura rígida e pré-definida? Seria seguro e fácil alterar esse tipo de arquitetura? É aqui que o TDD se torna muito importante!
Quando precisamos alterar algum código, precisamos nos certificar de que tudo que funcionava antes da alteração, também funcionará depois da alteração. A melhor forma de garantir isso é utilizando testes automatizados. Os testes facilitam o refactoring e permitem verificar rapidamente o que funciona e o que não funciona no sistema.
Como descrito no livro Test Driven Development By Example de Kent Beck (Beck2003), os seguintes passos resumem a prática:
Neste mesmo livro, estão relacionadas algumas das possíveis perguntas a serem respondidas:
Essas e outras questões, bem como detalhes técnicos sobre como praticar o TDD serão abordados no Workshop sobre Test Driven Development realizado pela Fratech. Se seu sistema anda com problemas na hora de refatorar ou sua produtividade está restrita, mesmo quando utiliza metodologias ágeis em seus projetos, não deixe de participar.
Putz cara! Muito bom, simples e direto ao ponto, gosto muito desse tipo de artigo. Parabéns.
Enviado por Manoel Pimentel em 03/04/2009 às 14:26