Acompanhando o agitado blog onde ele afirmava que "quem continua a pensar que TDD o deixa lento, está "vivendo na idade da pedra", Bob Martin dá uma lição ao fornecer um conhecimento mais profundo da aplicabilidade real, função e benefício TDD.
Ele começa por uma grande questão: "O TDD é um substituto para a arquitetura?". Sua resposta, 'Não, mas ...':
A noção de que você pode gerar uma arquitetura viável, começando com uma tela em branco e, em seguida, escrever um caso de teste após o outro é pura bobagem. Existem decisões que você precisa para fazer, e que não têm nada a ver com os testes.
Claro que muitas dessas decisões podem, e devem, ser prorrogadas por mais tempo possível. Por exemplo, o esquema de banco de dados é algo que pode provavelmente esperar por mais tempo. A decisão de utilizar Spring, JSF, Hibernate, JPA, etc, pode também esperar. O interessante das regras de negócio é que elas podem e devem ser implementadas independentemente da base de dados e modelos GUI.
...
Agora o mais importante. Você não pode gerar uma arquitetura completa com TDD. TDD pode te dar algumas das suas decisões de arquitetura, mas você não pode começar um projeto sem uma visão arquitetural. Logo, alguma arquitetura inicial é necessária. Uma das mais importantes atividades de quem decide pela arquitetura é decidir quais elementos arquiteturais podem ser postergados e quais não.
Tendo respondido à questão de arquitetura, Martin aborda o outro tópico lógico: "O TDD é um substituto para o design?". A essência de sua resposta é:
Não. Você ainda precisa de todos os skills de design. Você ainda precisa saber os princípios de design e padrões de design. Você deve saber UML. E, sim, você deve criar designs menores de seus projetos de sistemas.
...
O principal é que TDD é uma técnica de design, mas não deve ser a técnica de design exclusiva Todas as regras e técnicas antigas de concepção ainda podem ser utilizadas; e o TDD é uma poderosa forma de descobrir e ampliar essas regras.
Voltando à declaração sobre "idade da pedra", em seu blog, Martin se coloca a pergunta: "TDD deve ser utilizado para cada linha de código?". Novamente, a resposta é "não":/p>
Não. Há um conjunto de problemas para os quais TDD não é particularmente útil. GUIs são um exemplo.
...
Claro que não são apenas GUIs. É a noção de trivial que é a chave.Se você deve massagear o código em seu lugar. Se você precisa alterar with some aspect in order to please the customer. Se há alguma incerteza que só pode ser resolvida por um ciclo mais rápido de codificação, então TDD é provável que seja mais um obstáculo do que uma ajuda.
...
O truque para gerir isso é uma intensa dissociação. Esteja certo que consiga identificar cada pedaço do código que não precisa ter ajustes especiais separe esse código em módulos que você pode escrever com TDD. Certifique-se de que o código ajustado é isolado e seja o mínimo possível.
Mesmo admitido que alguns testes são de fato melhor escritos depois, Martin continua a acreditar que isso deve ser feito somente quando necessário (quando tiverem "ajustes" no código). Para ele, a principal razão é que isso "aumenta muito as chances de cada linha e cada decisão serem testadas", explicando até como mesmo os programadores mais experientes tendem a escrever código sem testes, se os testes não são escritos primeiros.
Uncle Bob, em seguida, coloca uma questão interessante: "Dado que nós aceitamos a necessidade dos testes, porque a resistência ao primeiro teste?". Para isso, ele propõe a hipótese de que algumas pessoas simplesmente não são capazes de pensar por meio de código de forma incremental:
Honestamente, eu não sei [por que existe essa resistência elevada a um primeiro teste]. É claro que não pode ser um problema de produtividade já que iremos escrever os testes de qualquer maneira.
Talvez algumas pessoas não gostem do fato de que, os testes sendo escritos primeiro interrompem o fluxo. É verdade, quando você escreve os testes primeiro, você não pode escrever um algoritmo inteiro. Você tem que montar o algoritmo pouco a pouco, à medida que vai adicionando o caso de teste. Talvez algumas pessoas não se sintam confortáveis para trabalhar desta forma.
Nas observações finais, Martin responde à questão bem comum: "Não seria mais rápido sem [ter que se preocupar] com toda essa cobertura nos testes?". Primeiro, ele admite que criar uma grande cobertura (de testes) para um ambiente legado (onde o código não possui testes) exige investimento elevado de longo prazo. Em ambientes não-legado e para código novo dentro de um ambiente legado, porém, sua resposta é bem diferente, pois neste caso, a automatização na cobertura de testes te dará mais rapidez. Suas razões para isso:
Em primeiro lugar, você não precisará fazer "debug" frequentemente. Como você o faria (debug) se você já tivesse testado virtualmente cada linha de código? Minha própria experiência com a depuração é que ela praticamente desaparece. No último ano, de intenso esforço de desenvolvimento no FitNesse, eu gastei pouquíssimo tempo na depuração. Se eu tivesse de quantificar esse tempo, eu iria colocá-lo em 5 horas ou menos.
Em segundo lugar, eu simplesmente não posso inadvertidamente quebrar o código. O conjunto de testes encontra essa ruptura em segundos! E isso me assusta. Quando você é destemido, pode ir muito mais rápido.
Em terceiro lugar, meus testes são pequenos exemplos de como funciona o sistema. Sempre que esqueço como alguma parte do sistema funciona, eu leio os testes. Os testes rapidamente me trazem o entendimento.
Em quarto lugar, eu não estou na constante luta contra os erros de campos. Mesmo com milhares de usuários, a minha lista de problemas é muito pequena. O tempo que gasto em apoio é menor que uma hora por semana, e geralmente só apontando as pessoas para o lugar certo no guia do usuário.
Veja no blog do Bob mais detalhes e exemplos concretos dessas idéias, e separe um tempo para ler os diversos feedbacks e as preciosidades nos comentários.