9.2
Definindo o teste de aceitação do primeiro cenário . . . . . . . . . . . 171
9.3
Melhore a testabilidade do seu software . . . . . . . . . . . . . . . . . . 175
9.4
Pontos-chave deste capítulo . . . . . . . . . . . . . . . . . . . . . . . . 184
10 Finalizando a segunda funcionalidade
187
10.1
Refatorando nosso jogo para ter uma máquina de estados . . . . . . . 187
10.2 Refatorando o fluxo do jogo para usar a máquina de estados . . . . . 193
10.3 Organizando seus testes otimizando para leitura . . . . . . . . . . . . 198
10.4 Interface discovery utilizando test doubles . . . . . . . . . . . . . . . . 201
10.5 Finalizando a funcionalidade Adivinhar letra . . . . . . . . . . . . . . 219
10.6 Pontos-chave deste capítulo . . . . . . . . . . . . . . . . . . . . . . . . 229
11 Finalizando nosso jogo
231
11.1
Especificando o fim do jogo . . . . . . . . . . . . . . . . . . . . . . . . 231
11.2
Jogador vence o jogo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
11.3
Jogador perde o jogo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
11.4
Próximos passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Bibliografia
249
Versão: 16.2.23
xi
Capítulo 1
Visão geral sobre TDD
Uma das melhores qualidades da comunidade Ruby é o uso constante de TDD (test-
driven development). Todo projeto open-source famoso na nossa comunidade tem
uma suíte de testes automatizados. É o padrão e o dia a dia de todo desenvolvedor
Ruby. Se você ainda não faz isso, você não é um desenvolvedor Ruby completo. Ao
ler este livro, você está dando mais alguns passos em direção a ser um desenvolvedor
melhor.
Durante a leitura deste livro, você irá aprender a fazer TDD, o Test-Driven De-
velopment, usando algumas das ferramentas mais famosas na comunidade Ruby: o
RSpec e o Cucumber. Você irá aprender sobre as ferramentas em si e também sobre
como aplicar a técnica de TDD para construir um software de mais qualidade.
Se você ainda não conhece ou conhece pouco sobre TDD, prepare-se, porque
essa prática irá mudar o modo como você escreve software... para melhor.
1.1. TDD e sua história
Casa do Código
1.1
TDD e sua história
A história de TDD começa principalmente no começo da década de 90, quando
Kent Beck escreve em Smalltalk sua primeira biblioteca de testes, o SUnit. A ideia
inicial dele era facilitar a execução de testes de software, automatizando essa tarefa que muitas das vezes era feita manualmente.
Alguns anos se passaram e em uma viagem de avião para o OOPSLA (Object-
Oriented Programming, Systems, Languages & Applications), tradicional evento
de
orientação a objetos, Kent Beck e Erich Gamma escreveram uma versão do SUnit
em Java, o JUnit.
O JUnit foi ganhando mais e mais espaço no mundo de desenvolvimento de soft-
ware, tendo vários ports feitos para outras linguagens como Ruby, C++, Perl, Python,
PHP e outras. Ao padrão da família formada por todas essas bibliotecas se deu o
nome de xUnit.
Ao passo que o uso das bibliotecas xUnit foi amadurecendo, utilizá-las não era
mais visto como apenas uma atividade de teste, mas sim como uma atividade de
design (projeto) de código. Essa visão faz sentido ao se pensar que antes de imple-
mentar um determinado método ou classe, os usuários de xUnit primeiro escrevem
um teste especificando o comportamento esperado, e depois fazem o código que vai
fazer com esse teste passe. A esse uso das bibliotecas xUnit, se deu o nome de test-
driven development (TDD).
No final da década de 90, Kent Beck formalizou o Extreme Programming (XP),
que viria a ser uma das principais metodologias ágeis de desenvolvimento de soft-
ware do mundo. O XP é formado por algumas práticas essenciais, entre elas o TDD.
Com a evangelização de TDD dentro do XP, a prática ganhou ainda mais tração,
sendo visto como uma das bases para o desenvolvimento de software com qualidade.
Entrando no mundo Ruby, a primeira biblioteca de testes automatizados na
nossa linguagem foi escrita por Nathaniel Talbott, batizada com o nome Lapidary.
Talbott apresentou o Lapidary na primeira RubyConf da história, em 2002. O Lapi-
dary deu origem ao Test::Unit, tradicional biblioteca xUnit em Ruby, que usamos
até hoje. Desde o começo da nossa comunidade, o uso de TDD e testes automati-
zados sempre foi a regra, e não a exceção. Como eu disse antes, todo projeto open
source em Ruby que se preza tem testes automatizados.
Em 2003, David Heinemeier Hansson (DHH) escreveu o Ruby on Rails (ou para
os íntimos, Rails). Rails se tornou o killer app da linguagem Ruby, ou seja, Rails é tão bom que as pessoas começaram a aprender Ruby só por causa dele. Como um dos
2
Casa do Código
Capítulo 1. Visão geral sobre TDD
softwares mais famosos escritos em Ruby, Rails também teve grande importância na
evangelização de TDD na nossa comunidade. Isso porque por padrão todo projeto
gerado pelo Rails já vem com um diretório específico para você colocar seus testes
automatizados, ou seja, Rails te convida a fazer TDD.