TDD não funciona.

Não? Isso é estranho. Eu sempre achei que funcionasse muito bem.

Não de acordo com um novo estudo.

Outro estudo?

Sim, um estudo aprofundado que repetiu outro estudo que foi feito há alguns anos. Ambos mostraram que TDD não funciona. O novo usa um multi-site, análise cega, aproximação. Parece conclusivo.

Os autores o consideram conclusivo?

Os autores recomendam mais estudos. Mas eles provavelmente só estão sendo humildes. Os dados são bastante convincentes.

Quais são os dados?

O estudo mostra que as alegações sobre TDD são falsas. TDD não faz você ir mais rápido, não reduz defeitos e não ajuda você a escrever um código melhor.

Isso é muito estranho. Eu acho que TDD me faz ir mais rápido, melhora o meu código e a minha precisão. Conheço outras pessoas que disseram o mesmo. Então, eu estou perplexo sobre por que esse estudo iria mostrar algo diferente.

Bem, ele mostrou. DHH estava certo. TDD está morto.

Hmmm. OK, então o que exatamente os autores estudaram? Como chegaram a essa conclusão?

Eu não sei, eu só sei que houve um estudo.

Como você descobriu sobre o estudo?

Eu li um blog sobre isso. No final, o autor disse que o estudo o fez reconsiderar o TDD. Ele costumava pensar que funcionava.

OK, bem, vamos olhar para o estudo. Hmmm. Sim, aqui diz que eles compararam TDD com TLD.

O que é TLD?

Test LAST development. Isso é quando você escreve seus testes unitários depois que você escreve seu código.

Percebe? Assim, o estudo mostrou que é melhor escrever seus testes por último!

Hmmm. Não, isso não parece ser o que o estudo mostrou. Na verdade, o estudo constatou que não houve diferença significativa.

OK, tudo bem. Então, se eu escrever o meu código e, em seguida, escrever meus testes é tão bom quanto TDD.

Bem, não, não completamente. Pelo menos isso não é o que o estudo mostrou. O estudo pediu ao pessoal que estava fazendo TLD que trabalhassem  nos “pequenos pedaços”.

Pequenos pedaços?

Sim. As pessoas que fazem TLD escreveriam um pouco de código de produção, seguido por um pouco de código de teste.

Oh. Entendo. Então, eles escreveriam código de produção por 10 minutos e depois escreveriam testes unitários por dez minutos ou algo assim.

Bem, talvez. Mas, veja, aqui diz que todos os participantes foram treinados em TDD. E, em seguida, alguns deles foram convidados a fazer TLD em pequenos pedaços.

Certo. OK. Então, minha declaração ainda é válida. Eles escreveram código de produção, então escreveram testes unitários, e isso não importa.

Então deixe-me perguntar como você escreveria testes unitários, após o código de produção, mas em pequenos pedaços?

Eu escrevia algum código de produção – o suficiente para passar um teste ou dois – e então eu escrevia esses testes.

Como você saberia quanto código passaria um teste ou dois?

Eu pensaria em alguns testes para passar, então eu escreveria o código que passaria por esses testes. Em seguida, eu escreveria os testes.

E já que você tinha sido treinado em TDD, esse tipo de processo de pensamento seria natural para você, não seria?

Hum. Hmmm. Acho que entendo o que você quer dizer. Os TLDs estavam fazendo TDD em suas cabeças e, em seguida, apenas revertendo a ordem.

Certo. A fim de trabalhar em pequenos pedaços, eles tiveram que imaginar os testes que eles estariam escrevendo para que pudessem escrever código de produção que fosse testável.

Então, talvez esse estudo não estivesse estudando o que eles pensavam estar estudando.

Parece-me que eles estavam tentando estudar a ordem da escrita dos testes, mais do que o processo de TDD. Em seu esforço para reduzir o número de variáveis, eles inadvertidamente eliminaram todas elas. Eles forçaram os participantes a fazer TLD para usar o processo TDD de ciclos curtos, e isso forçou os participantes a dirigirem o código de produção pensando em testes primeiramente.

OK. Talvez. Mas, mesmo assim, aqueles TLDs de fato escreveram seus testes por último. Assim, pelo menos, o estudo mostrou que você realmente não tem que escrever os testes primeiro, contanto que você trabalhe em ciclos muito curtos.

Certo. A parte realmente eficaz do TDD é o tamanho do ciclo, não tanto se você escreve o teste primeiro. A razão pela qual escrevemos os testes primeiro é que isso nos encoraja a manter os ciclos realmente curtos.

Então, o que o estudo mostrou é que as pessoas que trabalham em ciclos curtos não precisam se preocupar em escrever os testes primeiro, desde que continuem a trabalhar em ciclos curtos.

Essa é provavelmente uma afirmação justa. No entanto, veja aqui. O problema que os participantes estavam resolvendo era The Bowling Game. Esse é um problema muito pequeno. Na verdade, eles disseram que toda a sessão de programação levou três horas.

Isso é importante?

Claro. O benefício de escrever os testes primeiro é disciplinar. Escrever o teste primeiro mantém seus ciclos curtos e sua cobertura alta, durante longos períodos de tempo.

OK, mas se você tivesse disciplina interna suficiente para manter seus ciclos curtos, então o estudo mostra que não importa se você escreve seus testes primeiro.

Isso é um grande “se”, mas com certeza. O estudo mostra que se você pegar um grupo de pessoas treinadas em TDD e, em seguida, dizer-lhes para manter tudo da mesma forma, incluindo o tamanho de seus ciclos e apenas alterar a ordenação dos testes, então em três horas de programação você não verá muita diferença.

Sim. Sim. É isso que o estudo mostra.

Então, de fato, o estudo estava fazendo uma distinção sem uma diferença.

Bem… Heh, heh, eles não encontraram diferença, então eu acho que isso está certo.

Então o estudo não mostrou que o TDD não funciona, mostrou?

Não, acho que não.

O que ele mostrou?

Eu acho que ele mostrou que você não pode interpretar as conclusões de um estudo sem ler o estudo.

***

Robert Martin faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-work.html.