Disputa TDD: Mozart x Beethoven

Defendo, sim, que todo desenvolvedor deva utilizar TDD (Test-driven Development) para construir software. Mas isso não significa que eu tenha perdido meu senso crítico. Não se trata de uma paixão irracional, mas da constatação de que, em geral, a técnica traz resultados muito positivos. Contudo, existem situações em que alguns princípios do TDD são colocados em cheque. Por exemplo, o princípio de que “devemos programar o mínimo possível para fazer um teste passar” e, através de “passos de bebê“, construir de forma incremental o comportamento em questão.

O problema aqui não é se a técnica TDD é boa ou má, mas se essa forma de pensar “passos de bebê” é sempre, em todos os casos, a melhor. Vou tentar ilustrar a questão falando de dois compositores excepcionais. Quem será que se adequaria melhor ao TDD, Mozart ou Beethoven?

Beethoven foi o compositor mais importante na transição entre o período clássico (após o barroco) e o romântico. Sua forma de compor baseava-se em muitos rabiscos e rasuras (refatoração), refinando seu trabalho até chegar um momento em que ele se dava por satisfeito e decidia que a música estava finalizada (processo incremental).

Mozart foi um compositor que demonstrou ser um prodígio em violino e piano desde sua infância. Também do período clássico (1750 a 1820), a música de Mozart surgia antes em seu interior, de modo tal que quando ele parava para escrevê-la, ela já estava completamente pronta. Não havia rasuras ou refatorações. Mozart não dava passos de bebê! Ele sentava e escrevia a música completamente acabada e perfeita.

Beethoven e Mozart representam duas formas de pensar. Dois estilos. Beethoven trabalha de forma mais incremental, refatorando até se dar por satisfeito. Mozart rumina interiormente sua música, até que ela esteja definida. Só então ele parte para escrevê-la.

Embora estejamos falando de duas pessoas distintas, todos nós podemos lançar mão de uma ou outra abordagem de acordo com a situação. Em minha experiência com TDD, já houve situações nas quais tinha de implementar certo comportamento de negócio, e minha atitude foi refletir sobre o problema por alguns dias, enquanto trabalhava com outras coisas, e depois parar diante de um quadro branco, e desenvolver algumas equações matemáticas que me davam a resposta que eu queria. Ao partir para escrever o código, não fazia mais sentido dar passos de bebê. Eu já tinha o problema todo resolvido com aquelas equações. Eu construí o primeiro teste, codifiquei a equação que se mostrou mais simples do que parecia e facilmente o primeiro teste passou. Depois codifiquei vários outros testes que prontamente davam verde, sem passar pelo vermelho. “O que eu fiz de errado?” me perguntava. Na verdade, nada. Só não fazia sentido dar passos de bebê quando essa parte do meu problema já estava completamente compreendida e revolvida. Mas ainda assim fiz os vários testes para garantir a cobertura de todos os cenários, mas de fato isso deixou de ser “test-first”.

Concluindo, embora a grande maioria dos comportamentos de software que construímos sejam bem aderentes à técnica do TDD, em algumas situações específicas precisamos entender que TDD é um meio, e não o fim. Se Mozart decidisse desenvolver software, ao contrário de Beethoven, provavelmente  não se daria tão bem com TDD.

Crédito da imagem: http://www.almanaqueestacao.com.br/musica/partitura%20amadeus%20mozart.htm