Eu gosto de pensar que tenho a mente aberta para não cair na
armadilha de me tornar fanático. Procuro ler críticas negativas de coisas
que gosto, como por exemplo Test Driven Development. O duro é encontrar.

A busca no Google

Para começar minha busca, eu digitei “TDD sucks” no Google. O primeiro resultado da busca é basicamente de alguém que gosta de TDD, mas acha que sucks não pode
se aplicar ao contexto empresarial onde o cara está, já que a empresa
lucra com correção de bugs. Ok, isso é na verdade um elogio.

Já o segundo link
é de um cara que acha que o que sucks é o tedioso processo de começar a escrever testes sem estar acostumado.
Mas ele já está vendo os benefícios e está totalmente convertido. Ok…

O terceiro resultado é intitulado top 10 razões porque TDD sucks. Não é preciso ler
todos os itens pra perceber que o autor está de forma irônica dizendo
algo na linha de “TDD: você está fazendo isso errado”. Em resumo: alguém que
gosta de TDD tentando ensinar às pessoas a praticá-lo.

O quarto link é de uma thread
num fórum de desenvolvedores. A discussão é interessante, mas até onde
li não entendi o porque do título… Provavelmente também terá um sentido
irônico, assim como este artigo.

O quinto resultado da pesquisa diz que “TDD sucks” mas que “desenvolver sem TDD também sucks”. E
que se você forçar um time que está aprendendo a escrever testes e fazer
TDD com a camada de interface com o usuário, eles irão fazer testes
horríveis que quebram toda hora. Normal.

Encontro serendipitoso

Foi então que hoje li um ótimo artigo
do Fabrício Matos falando sobre os perigos de se empolgar demais com
algo (neste caso, TDD) e começar a defender cegamente esse algo. Vocês podem conferir a crítica Mantenha a mente aberta. TDD nem sempre é o melhor! publicada aqui no iMasters.

Eu
basicamente concordo com o texto. E também concordo com a conclusão a
que ele chegou, concordando inclusive com o post de Mike Tayler a que ele se
refere. Mas tem só um probleminha… Deixe-me dar um exemplo.

Suponha que você tenha como requisito algo como “o cadastro de
clientes deve ser exibido em ordem alfabética”. E que você nunca tenha
ouvido falar em algoritmos de ordenação na vida.

Você irá escrever um
monte de testes para verificar se a listagem está vindo em ordem, e
provavelmente irá terminar com uma versão capenga e desajeitada do
BubbleSort ou InsertionSort.

Você não é um matemático do calibre dos que
provaram a complexidade do QuickSort ou MergeSort. Lamento, mas você
não é. Você está aí implementando cadastro de clientes!

Se bem praticado, o TDD irá te conduzir à produção de um cadastro de
clientes que terá as responsabilidades dos objetos bem definidas. Você
terá criado em algum momento uma classe chamada “ordenador” ou algo
assim. Então você vai se empolgar quando perceber que sua classe pode
ser generalizada para ordenar qualquer coisa, não somente clientes por
nome.

Você irá então até pensar em mover o código para o framework da
empresa. Cedo ou tarde a ficha irá cair que este problema já foi
resolvido antes por outra pessoa em algum outro lugar de forma mais
eficiente.

Minha conclusão

O ponto central aqui é: TDD é uma técnica de desenvolvimento de software, não de algoritmos. Ninguém está dizendo que TDD conduz a
bons algoritmos, mas ao bom código. Código que implemente algoritmos,
ou que os use, mas não os algoritmos em si.

E, ao contrário do que muitos talvez possam sonhar, não desenvolvemos
algoritmos mas sistemas. Sistemas tediosos, repetitivos, sistemas que
emitem relatórios para o governo, sistemas que integram com módulo de
nota fiscal eletrônica. Sistemas que são um saco. E é para eles que TDD
serve.

E é por isso que TDD é um saco.