fez mudar de ideia foi justamente o fato de termos encontrado um teste com uma
característica estranha (a não-necessidade de um cenário para a classe sob teste).
Esse é o principal ponto deste capítulo. Muitos praticantes de TDD afirmam que
a prática lhes guia no projeto de classes. A grande pergunta é: como isso acontece?
Isso é outro ponto bastante curioso e mal entendido sobre TDD. Apesar de muitos
praticantes de TDD acreditarem que a prática guia a criação do design, poucos sabem
explicar como isso realmente acontece. Esta é, aliás, o grande ponto que este livro
tenta atacar.
A prática de TDD pode influenciar no processo de criação do projeto de classes.
No entanto, ao contrário do que afirmações mais superficiais fazem parecer, a prá-
tica de TDD não guia o desenvolvedor para um bom projeto de classes de forma
automática; a experiência e conhecimento do desenvolvedor são fundamentais
ao criar software orientado a objetos.
A prática, por meio dos seus possíveis feedback em relação ao projeto de classes,
que serão discutidos em detalhes nos capítulos a seguir, pode servir de guia para o
desenvolvedor. Esses feedback, quando observados, fazem com que o desenvolvedor
perceba problemas de projeto de classes de forma antecipada, facilitando a refato-
ração do código. Um exemplo desses feedback foi justamente o que observamos no
primeiro teste que escrevemos. O teste não montava qualquer cenário na classe que
estava sob teste. Isso simplesmente não parecia correto. São pequenas dicas como
essas, que ajudam o desenvolvedor a optar por um melhor projeto de classes.
55
5.3. Diferenças entre TDD e testes da maneira tradicional
Casa do Código
Portanto, esta é a forma na qual a prática guia o desenvolvedor para um melhor
projeto de classes: dando retorno constante sobre os possíveis problemas existentes
no atual projeto de classes. É tarefa do desenvolvedor perceber esses problemas e
melhorar o projeto de acordo.
5.3
Diferenças entre TDD e testes da maneira tra-
dicional
O desenvolvedor que
pratica TDD escreve os testes antes do código. Isso faz com
que o teste de unidade que está sendo escrito sirva de rascunho para o desenvol-
vedor. Foi novamente o que fizemos. Começamos pelo teste e, ao perceber que o
teste estava estranho, o jogamos fora e começamos outro. O custo de jogá-lo fora
naquele momento era quase zero. Não havíamos escrito uma linha na classe de pro-
dução. Tínhamos a chance de começar de novo, sem qualquer perda.
Mas o mesmo feedback poderia ser obtido caso o desenvolvedor deixasse para es-
crever o teste ao final da implementação. Mas então qual seria a vantagem da prática
de TDD?
Ao deixar a escrita do teste somente para o final, no momento que o desenvolve-
dor perceber um problema de design graças ao teste, o custo de mudança será alto.
Leve isso para o mundo real, onde o programador escreve dezenas de classes que
interagem entre si e só depois ele escreve o teste.
Todas as decisões de design (boas ou ruins) já foram tomadas. Mudar algo nesse
momento pode ser caro, afinal uma mudança em uma classe pode impactar em mui-
tas mudanças nas outras classes que dependem da classe alterada.
O praticante de TDD não tem esse problema. Afinal, graças a escrita do teste
antes e à simplicidade inerente do processo, ele escreve um teste para uma pequena
funcionalidade, recebe feedback dela, faz as mudanças que achar necessário e im-
plementa. Depois, ele repete o ciclo. Ou seja, o praticante de TDD recebe feedback
constante ao longo do seu dia a dia de trabalho, fazendo-o encontrar possíveis pro-
blemas de design mais cedo e, por consequência, diminuindo o custo de mudança.
56
Casa do Código
Capítulo 5. TDD e Design de Classes
Fishbowling no Encontro Ágil
Ao longo do meu mestrado, participei e conversei com diversas pessoas
praticantes ou interessadas em TDD. Em um desses eventos, o Encontro
Ágil de 2010, organizei um pequeno debate sobre o assunto [27]. Éra-
mos em torno de 12 pessoas discutindo sobre TDD (eu não participei da
discussão, apenas a moderei), e ficamos lá por 1h30.
E durante toda a conversa, praticamente todos os participantes afirma-
vam firmemente que TDD os ajudava a produzir classes melhores. Mas,
quando perguntei como isso acontece exatamente, todos eles passaram
a falar menos. Eles não sabiam dizer como a prática os guiava, apenas
sentiam que isso acontecia.
Essa foi uma das grandes motivações da minha pesquisa de mestrado
e deste livro sobre o assunto. Realmente não é claro para todos como
TDD guia o desenvolvedor. Espero com este livro mostrar, de maneira
explícita, como isso acontece.
5.4
Testes como rascunho
Observe o teste abaixo:
[Test]
public void DeveRetornarValorDoItemSeCarrinhoCom1Elemento()
{
CarrinhoDeCompras carrinho = new CarrinhoDeCompras();
carrinho.Adiciona(new Item("Geladeira", 1, 900.0));
Assert.AreEqual(900.0, carrinho.MaiorValor(), 0.0001);
}
Repare que, apesar de simples, ele deixa bem claro uma grande quantidade de