Tecnologia. Inteligente.

Este livro do Kent Beck, apesar de já estar com seus 6 aninhos, uma eternidade no mundo volátil da computação, continua sendo uma referência importante de alguns conceitos importantes da engenharia de software. Portanto, é sempre bom tê-lo na biblioteca.

A proposta é radical. Seu código tem que ser testável para que você tenha controle sobre as mudanças que fizer nele, pq mudanças = novos bugs. Ao mesmo tempo, se você escreve os testes antes do código, você é forçado a conhecer melhor a especificação do que ele faz. Seus testes se tornam, a uma granularidade muito pequena, uma especificação do seu código. Escrever teste (especificação) e escrever código, repetidamente. Quando seu código começar a crescer, refatorar (opa, vamos falar deste outro livro do Beck mais à frente), retirar as redundâncias, seguro que suas modificações não afetarão o código, e se afetar, que os testes irão lhe mostrar onde.

É basicamente isto o que o livro advoga. Desenvolver aos poucos, começando sempre pelos testes, refatorando quando necessário. Me dá uma sensação de crescimento celular de código, como se fosse uma célula absorvendo nutrientes, crescendo e se dividindo, até formar estruturas mais complexas. Se funcionou na natureza, funciona para a programação?

Há quem advogue que a técnica leva a arquiteturas pobres e mal planejadas, ou que perde-se muito tempo no processo, tanto escrevendo os testes como mantendo estes mesmos testes quando as coisas mudam lá na frente. De fato, manter um código com boa cobertura de testes é, para os desacostumados, caro e doloroso. A prática promete ganhos futuros argumentando que bugs são caros porque levam tempo para serem encontrados e corrigidos, e num mundo onde o atraso de deadline significa multa contratual, qualidade não é mais um luxo, é um requisito.

Na prática, os resultados são bastante distoantes. Alguns evangelistas defenderão até a morte que TDD é uma bala de prata, enquanto outros dirão que é caro demais. Procurando algum embasamento, achei este interessante paper da Microsoft sobre o resultado do uso de TDD em dois de seus projetos, um em C++ e outro em .NET. Obviamente, linguagens com maiores facilidades de OO são beneficiados com TDD, então os resultados para .NET foram melhores que para C++. Ainda, os resultados foram bastante positivos em ambos os projetos, mostrando ganhos de qualidade (contados por números de bugs) muito significativos (melhorias de 2,6 a 4,2 vezes) a um custo médio em torno de 15% a 30% a mais de tempo. Consistentemente, algumas linguagens permitem ganhos maiores a um custo menor de tempo, então TDD não é uma bala de prata para qualquer linguagem, como gostariam de acreditar alguns. Ou pelo menos, não tão bom quanto é para JAVA ou .NET por exemplo.

A experiência ensina a duras penas aos desenvolvedores que tudo tem um custo, mesmo a hype mais miraculosa. Ciente da realidade, TDD é uma técnica e tanto, que em termos práticos, traz ganhos muito significativos e palpáveis. Difícil é determinar até onde o tradeoff de esforço e qualidade vale a pena.