sário para resolver o problema naquele momento, comecei a perceber
que poderia gastar meu tempo implementando funcionalidades que re-
almente agregariam valor para o usuário final.
Portanto, não ache que ser simples é fácil. Lembre-se que somos atraí-
dos por complexidade.
3.5
Um pouco da história de TDD
TDD ficou bastante popular após a publicação do livro TDD: By Example, do Kent
Beck, em 2002. O próprio Kent afirma que TDD não foi uma ideia totalmente ori-
ginal. Ele conta que em algum momento de sua vida, que leu em algum dos livros
de seu pai (que também era programador), sobre uma técnica de testes mais antiga,
onde o programador colocava na fita o valor que ele esperava daquele programa, e
então o programador desenvolvia até chegar naquele valor.
Ele próprio conta que achou a ideia estúpida. Qual o sentido de escrever um
teste que falha? Mas resolveu experimentar. Após a experiência, ele disse que as
pessoas sempre falavam pra ele conseguir separar o que o programa deve fazer, da
sua
implementação final, mas que ele não sabia como fazer, até aquele momento em
que resolveu escrever o teste antes.
Daquele momento em diante, Kent Beck continuou a trabalhar na ideia. Em
1994, ele escreveu o seu primeiro framework de testes de unidade, o SUnit (para
Smalltalk). Em 1995, ele apresentou TDD pela primeira vez na OOPSLA (conferência
muito famosa da área de computação, já que muitas novidades tendem a aparecer lá).
30
Casa do Código
Capítulo 3. Introdução ao Test-Driven Development
Já em 2000, o JUnit surgiu e Kent Beck, junto com Erich Gamma, publicou o
artigo chamado de Test Infected [1], que mostrava as vantagens de se ter testes
automatizados e como isso pode ser viciante.
Finalmente em 2002, Kent Beck lançou seu livro sobre isso, e desde então a prá-
tica tem se tornado cada vez mais popular entre os desenvolvedores.
A história mais completa pode ser vista na Wiki da C2 [2] ou na palestra do Steve
Freeman e Michael Feathers na QCON de 2009 [16].
Ferreira fala
Duas histórias muito conhecidas cercam Kent Beck e o nascimento dos
primeiros frameworks de testes unitários. O SUnit, para Smalltalk, não
era um código distribuído em arquivos da maneira usual. Beck na época
atuava como consultor e tinha o hábito de recriar o framework junto com
os programadores de cada cliente. A criação do JUnit também é legen-
dária: a primeira versão foi desenvolvida numa sessão de programação
pareada entre o Kent Beck e o Erich Gamma em um voo Zurique-Atlanta.
3.6
Conclusão
Neste capítulo, apresentamos TDD e mostramos algumas das vantagens que o pro-
gramador obtém ao utilizá-la no seu dia a dia. Entretanto, é possível melhorar ainda
mais a maneira na qual o programador faz uso da prática.
Somente praticando TDD com esse simples exemplo, é possível levantar diversas
questões, como:
Muitos cenários foram deixados para trás, como por exemplo, a conversão de
números como CC, MM, e etc. Eles devem ser escritos?
O inverso da pergunta anterior: testes para I, V, X devem ser considera-
dos diferentes ou repetidos?
E quanto a repetição de código dentro de cada teste? É possível melhorar a
qualidade de código do próprio teste?
A ideia de sempre fazer o teste passar da maneira mais simples possível faz
sentido? Deve ser aplicado 100% do tempo?
31
3.6. Conclusão
Casa do Código
Existe alguma regra para dar nomes aos testes?
Qual o momento ideal para refatorar o código?
Se durante a implementação, um teste antigo, que passava, quebra? O que
devo fazer?
Para que um desenvolvedor faça uso de TDD de maneira profissional e produ-
tiva, estes e outros pontos devem ser discutidos e clarificados. Nos próximos capítu-
los, responderemos a cada uma dessas perguntas, usando como exemplo um sistema
razoavelmente complexo muito similar aos encontrados no mundo real.
32
Capítulo 4
Simplicidade e Baby Steps
No capítulo anterior, apresentamos TDD em um exemplo complexo do ponto de
vista algorítmico, mas bem controlado. Mesmo assim, o capítulo anterior foi muito
útil e serviu para mostrar os passos de um desenvolvedor que pratica TDD.
O mundo real é mais complexo do que isso; algoritmos matemáticos são com-
binados e interagem com entidades que vem do banco de dados e são apresentados
para o usuário através de alguma interface. De agora em diante, os exemplos a serem
trabalhados serão outros e, com certeza, mais parecido com a realidade. No mundo
real, as coisas evoluem e mudam rapidamente. Portanto, nos próximos exemplos,
sempre imagine que eles ficarão mais complexos e evoluirão.
4.1
O Problema do Cálculo de Salário
Suponha que uma empresa precise calcular o salário do funcionário e seus descontos.
Para calcular esse desconto, a empresa leva em consideração o salário atual e o cargo do funcionário. Vamos representar funcionários e cargos da seguinte maneira:
4.2. Implementando da maneira mais simples possível
Casa do Código
public enum Cargo
{
DESENVOLVEDOR,
DBA,
TESTADOR
}
public class Funcionario