Logo Fratech

Test Driven Development & Design Evolutivo

Publicado por: Felipe Rodrigues de Almeida
em: 02 Apr 2009 às 19:24

TDD: Todo código é culpado até que se prove o contrário!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.

Benefícios do 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.

Ciclo do TDD

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.

Mas como isso acontece na prática?

Como descrito no livro Test Driven Development By Example de Kent Beck (Beck2003), os seguintes passos resumem a prática:


  1. Rapidamente adicione um teste
  2. Execute todos os testes e veja que o teste novo falha
  3. Realize um pequena alteração no código
  4. Execute todos os testes e veja se todos tem sucesso
  5. Refatore para remover duplicação.

Neste mesmo livro, estão relacionadas algumas das possíveis perguntas a serem respondidas:


  • Como cada teste pode tratar de um pequeno incremento de funcionalidade?
  • Quão pequenas e feias as mudanças podem ser para conseguir fazer os novos testes funcionarem?
  • Com que freqüência os testes são executados?
  • Quantos passos formam os refactorings?

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.

Tags: | XP | Agile | Design Evolutivo | TDD |
1 comentários

Show de bola

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

Deixe sua opinião:

Você deve ser cadastrado para enviar comentários. Caso não seja cadastrado clique aqui


Ruby Rails Linguagens Dinâmicas Agile Groovy Scrum DDD Arquitetura Java TI FDD XP OO Ubiquitous Language JVM Ioke Merb Web Frameworks Requisitos FBS Backlog Design TDD Design Evolutivo Planejamento ti2.0 business agile









 
fratech@fratech.net
Fone / Fax:
+55 19 3454-5873
Rua Pedro Furlan, 232 - Miguel Grego
Sta Bárbara D'Oeste - SP
Cep: 13450-150
Copyright © 2009 - Fratech Tecnologia da Informação