Vimos o teste falhar;
Implementamos o código mais simples para resolver o problema;
Vimos o teste passar;
Melhoramos (refatoramos) nosso código quando necessário.
Esse ciclo de desenvolvimento é conhecido por Test-Driven Development
(TDD), ou, Desenvolvimento Guiado pelos Testes. A ideia é simples: o desenvolvedor deve começar a implementação pelo teste e, deve o tempo todo, fazer de
tudo para que seu código fique simples e com qualidade.
27
3.4. Quais as vantagens?
Casa do Código
Esse ciclo é também conhecido como ciclo vermelho-verde-refatora (ou red-
green-refactor). O primeiro passo é escrever um teste que falha. A cor vermelha
representa esse teste falhando. Em seguida, fazemos ele passar (a cor verde repre-
senta ele passando). Por fim, refatoramos para melhorar o código que escrevemos.
3.4
Quais as vantagens?
Muitos praticantes de TDD afirmam que executar esse ciclo pode ser muito vantajoso
para o processo de desenvolvimento. Alguns deles:
Foco no teste e não na implementação. Ao começar pelo teste, o programa-
dor consegue pensar somente no que a classe deve fazer, e esquece por um
momento da implementação. Isso o ajuda a pensar em melhores cenários de
teste para a classe sob desenvolvimento.
Código nasce testado. Se o programador pratica o ciclo corretamente, isso
então implica em que todo o código de produção escrito possui ao menos um
teste de unidade verificando que ele funciona corretamente.
Simplicidade. Ao buscar pelo código mais simples constantemente, o desen-
volvedor acaba por fugir de soluções complexas, comuns em todos os sistemas.
O praticante de TDD escreve código que apenas resolve os problemas que es-
tão representados por um teste de unidade. Quantas vezes o desenvolvedor
não escreve código desnecessariamente complexo?
Melhor reflexão sobre o design da classe.
No cenário tradicional, muitas ve-
zes a falta de coesão ou o excesso de acoplamento é causado muitas vezes pelo
desenvolvedor que só pensa na implementação e acaba esquecendo como a
classe vai funcionar perante o todo. Ao começar pelo teste, o desenvolvedor
pensa sobre como sua classe deverá se comportar perante as outras classes do
sistema. O teste atua como o primeiro cliente da classe que está sendo escrita.
Nele, o desenvolvedor toma decisões como o nome da classe, os seus métodos,
parâmetros, tipos de retorno, e etc. No fim, todas elas são decisões de design
e, quando o desenvolvedor consegue observar com atenção o código do teste,
seu design de classes pode crescer muito em qualidade.
Todos estes pontos serão melhor descritos e aprofundados no capítulo a seguir.
Nesse momento, foque nestas vantagens. Uma pergunta que pode vir a cabeça é:
28
Casa do Código
Capítulo 3. Introdução ao Test-Driven Development
"No modelo tradicional, onde os testes são escritos depois, o desenvolvedor não tem os mesmos benefícios?
A resposta é sim. Mesmo desenvolvedores que escrevem testes depois podem
obter as mesmas vantagens. Um desenvolvedor pode perceber que está com dificul-
dades de escrever um teste e descobrir que o design da classe que implementou tem
problemas; ele pode também conseguir abstrair a implementação e escrever bons
cenários de teste.
Mas há uma diferença que faz toda a diferença: a quantidade de vezes que um
programador praticante de TDD recebe feedback sobre esses pontos e a quantidade
que um programador que não pratica TDD recebe.
Veja a figura abaixo. O praticante de TDD escreve um pouco de testes, um pouco
de implementação e recebe feedback. Isso acontece ao longo do desenvolvimento de
maneira frequente. Já um programador que não pratica TDD espera um tempo (às
vezes longo demais) para obter o mesmo feedback.
Ao receber feedback desde cedo, o programador pode melhorar o código e corri-
gir problemas a um custo menor do que o programador que recebeu a mesma men-
sagem muito tempo depois. Todo programador sabe que alterar o código que ele
acabara de escrever é muito mais fácil e rápido do que alterar o código escrito 3 dias atrás.
No fim, TDD apenas maximiza a quantidade de feedback sobre o código que está
sendo produzido, fazendo o programador perceber os problemas antecipadamente
e, por consequência, diminuindo os custos de manutenção e melhorando o código.
29
3.5. Um pouco da história de TDD
Casa do Código
Desenvolvedores e a busca pela complexidade
Acho impressionante como nós desenvolvedores somos atraídos por
complexidade.
Gostamos de problemas difíceis, que nos desafiem.
Lembro-me que no começo de carreira, quando pegava alguma funci-
onalidade simples de ser implementada, eu mesmo aumentava a funci-
onalidade somente para torná-la interessante do ponto de vista técnico.
Ou seja, um simples relatório se tornava um relatório complexo, com di-
versos filtros e que podia ser exportado para muitos formatos diferentes.
Aprender a ser simples foi difícil. O TDD, de certa forma, me ajudou
nisso. Ao pensar de pouco em pouco, e implementar somente o neces-