Atenção: esse artigo tem uma palestra complementar. Clique e assista!

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Do que trata o artigo

O artigo mostra de forma prática o desenvolvimento de software utilizando Test-Driven Development (desenvolvimento guiado por testes).


Para que serve

Conhecer a prática de Test-Driven Development e entender como aplicá-la em cenários reais do dia-a-dia do desenvolvimento de software, entendendo quais os benefícios existentes em sua adoção e o por que ela nos proporciona fazer software para durar.

Em que situação o tema é útil

Test-Driven Development está relacionado com a escrita de código claro, limpo, de qualidade e feito para durar. Através dele podemos manter um registro de tudo o que nosso sistema é capaz de fazer, e desta forma conseguimos garantir que implementações e alterações futuras não quebrem o que já existe. Além disso, o TDD nos proporciona escrever código menos acoplado nos ajudando a garantir um melhor design de nossas classes e camadas, além de manter uma documentação executável de tudo que está contido em nosso sistema.

Resumo do DevMan

O Test-Driven Development já não é mais uma prática nova. Tendo sido oficialmente chamada de Test-Driven em meados de 2002, esta prática nos ensina a primeiro escrever testes para o nosso código para só depois escrever o código e, por fim, arrumá-lo para que fique mais claro e limpo. Este tipo de prática nos leva a diversos benefícios, como a obtenção de um melhor design, melhor entendimento e conhecimento do negócio, especificações mais claras e outros que serão abordados de forma prática neste artigo.

Talvez o Test-Driven Development venha sendo praticado há muitos anos por algumas pessoas, mas de fato o mesmo começou a se popularizar em meados de 2002, com a publicação do livro “Test-Driven Development by Example”, do autor Kent Beck. A grande promessa de Kent Beck no início do livro é a de conseguirmos produzir “clean code that works”, ou seja, “código limpo que funciona”.

De uma forma simples Kent Beck explica que o Test-Driven Development (que a partir de agora chamaremos só de TDD) é uma prática que possibilita ao desenvolvedor obter feedback de forma muito rápida sobre o código sendo escrito. É possível entender em poucos segundos o que está acontecendo e desta forma é possível aprender tudo o que o código pode nos ensinar. E se estamos obtendo feedback do código de forma rápida e aprendendo com o mesmo, podemos assim produzir um código limpo.

O TDD possui um mantra básico que irá nos guiar: Red/Green/Refactor. Primeiro escreva um teste. Este deve ser um teste que falhe e assim obteremos um red (uma falha no teste). Escreva então o código necessário para o teste passar. Neste ponto é permitido escrever qualquer tipo de código para que o teste passe e então obteremos um verde (um teste que funciona). Remova então todas as duplicações de código, e limpe-o, fazendo assim um refactoring.

Nota do DevMan

Refactoring é uma técnica utilizada para alterar a estrutura interna de um trecho de código sem alterar o comportamento existente. Cada uma destas transformações é chamada de refactoring. Para obter mais informações sobre refactoring visite a “Refactoring Home Page”, mantida por Martin Fowler (confira o endereço na seção de links ao final do artigo).

A ideia de escrever testes antes de escrever o código em si pode parecer estranha à primeira vista, no entanto ela é muito válida. Quando escrevemos um teste antes do código estamos pensando exatamente em como queremos que nosso código seja e como queremos que ele se comporte. Estamos desenvolvendo sob o ponto de vista de quem consome o nosso código, e desta forma escrevemos um código mais simples e claro. Este é um dos grandes benefícios do TDD – auxiliar e orientar o design da aplicação.

Outro enorme benefício do TDD é produzir classes com baixo acoplamento, ou seja, classes mais coesas, que realizam apenas o trabalho para o qual elas foram planejadas. O TDD nos obriga a desenvolver desta forma, e caso não façamos assim começaremos a perceber que está ficando muito difícil escrever um teste que deveria ser simples. Por fim, eu destacaria como o maior benefício do TDD a documentação executável. Os testes produzidos através do TDD funcionam como especificações de cada pequena regra de nosso sistema, e o mais impressionante é que podemos executar todas estas regras e verificar que elas estão funcionando agora, e que continuarão a funcionar após alguma modificação, caso contrário obteremos alguns vermelhos durante os testes.

...
Quer ler esse conteúdo completo? Tenha acesso completo