Daí pra frente, o resto é história. Hoje TDD é uma prática muito bem difundida
no mundo de desenvolvimento de software, sendo vista como uma das bases para
desenvolvimento de software com qualidade e de fácil manutenção.
1.2
E por qual motivo eu deveria usar TDD?
Em 1981, no livro Software Engineering Economics [2], Barry Boehm sugeriu que o
custo de alteração em um projeto de software cresce exponencialmente à medida que
se avança nas fases do desenvolvimento.
Figura 1.1: Custo de alteração em um projeto de software
Como o custo de alteração do software cresce muito ao longo das fases de desen-
volvimento, seria melhor fazer a maioria das alterações necessárias logo no começo
de um projeto, que seriam as fases de levantamento de requisitos e análise. Uma
metodologia que segue essa ideia é a Cascata (Waterfall).
Outra abordagem que pode ser tomada em relação a esse aumento exponencial
no custo de alteração é tentar reduzi-lo e mantê-lo mais constante ao longo do de-
senvolvimento do projeto e do ciclo de vida do software. Essa é uma das ideias de
metodologias ágeis, como o XP, onde uma das práticas que ajuda a diminuir esse
custo é o TDD.
3
1.2. E por qual motivo eu deveria usar TDD?
Casa do Código
Uma das consequências de fazer TDD é que o seu sistema fica coberto por uma
suíte de testes automatizados, de modo que toda vez que você for fazer uma mu-
dança no código, é possível rodar a suíte e ela então dirá se você quebrou algum
comportamento previamente implementado.
Segundo o XP, o desenvolvedor deve ao longo do projeto refatorar constante-
mente o código para deixar o design o melhor possível. Com a refatoração constante,
o design do software pode se manter bom, de modo que o custo de alteração do sis-
tema não cresça exponencialmente. Na prática, isso quer dizer que se no começo do
projeto leva
uma semana para adicionar uma funcionalidade, um ano depois, deve
continuar levando uma semana ou pouco mais do que isso. Essa manutenção do
custo de mudança do código em um nível baixo é uma das vantagens que se ganha
ao utilizar TDD.
Outra vantagem é a perda do medo de mudar o código. A possibilidade de poder
se apoiar na suíte de teste toda vez que você for modificar o software te da liberdade e coragem em mudar e adaptar o sistema de acordo com a necessidade do projeto,
por toda sua vida. Esse tipo de coisa permite, por exemplo, que você possa fazer mu-
danças arquiteturais no seu código, garantindo que ele irá continuar funcionando.
Permite também que novos integrantes da equipe possam conseguir contribuir mais
rapidamente no projeto, visto que eles não precisam ter medo de mudar o código.
Por fim, outra vantagem notada pelos praticantes e estudiosos de TDD é a me-
lhora no design do seu código. Existem vários exemplos mostrando uma relação
direta entre testabilidade e bom design. A ideia geral é que se seu código for difícil de testar, significa que ele pode estar acoplado demais ou com baixa coesão. TDD nos
ajuda a detectar esse tipo de problema, nos sugerindo melhorar o design do nosso
código. Essa vantagem vai ficar mais clara quando formos desenvolver um projeto
inteiro com TDD, a partir do capítulo 5.
Agora que você já conhece a história por trás do TDD e as vantagens de usá-lo,
vamos ver um exemplo simples de como é isso na prática e depois vamos falar sobre
a continuação dessa história e como ela culminou no que hoje conhecemos como
BDD (behavior-driven development).
4
Capítulo 2
Primeiros passos com RSpec e
Cucumber
Como desenvolvedor, conheço a nossa sede por ver código. Todo mundo já ouviu a
tradicional frase show me the code!. É por isso que ao invés de começarmos vendo os detalhes sobre RSpec e Cucumber, vamos primeiro ver uma espécie de hello world
para ambas as ferramentas.
Neste primeiro momento, o mais importante é que você possa ter uma ideia da
cara do RSpec e do Cucumber, e é isso que vamos fazer neste capítulo.
2.1
Olá RSpec
O RSpec é uma biblioteca de testes de unidade em Ruby que segue a filosofia do BDD,
que é uma extensão do TDD. Vamos falar melhor sobre BDD depois. Por enquanto
nosso objetivo é ver na prática como é escrever um pequeno programa seguindo
TDD e usando RSpec.
2.1. Olá RSpec
Casa do Código
Como você viu no capítulo 1, TDD não é considerado apenas uma prática de
teste, mas sim uma prática de design. Isso se faz verdade pois, ao seguir o TDD, você pensa na API (interface) do seu software antes mesmo de construí-lo. Você descreve
esse pensamento, essa especificação, em formato de teste automatizado. Uma vez
o teste feito, você desenvolve o pedaço de software que você acabou de especificar,
fazendo com que seu teste passe. Uma vez que o teste passou e está minimamente
atendido, você fica livre para refatorar o seu código, reduzindo duplicação, deixando-o mais claro e fazendo outras melhorias que você julgar necessárias. A esse fluxo do
TDD se dá o nome de red - green - refactor. Vamos aplicá-lo para ficar mais claro.