Este é o quarto post sobre um projecto em que tive de conciliar formalidade com agilidade, no qual abordarei a Construção do Sistema do ponto de vista do programador.

O príncipio orientador de todo o processo foi utilizar o Test-Driven Development (TDD), o que implica escrever os testes unitários antes do código em si (A parte "Red, Green" do mantra) e fazer Refactoring intensivamente (A parte "Refactor" do mantra). Consegui seguir a prática em toda a sua pureza? Não, por duas razões principais.

Em primeiro lugar, devido aos constrangimentos relacionados com a necessidade de ter um desenho detalhado antes de avançar para a construção, naturalmente que não pude escrever os testes antes do código, pelo menos a 100%. No entanto, estes constrangimentos não me impediram de alterar o desenho sempre que necessário e não me impediram de criar os testes antes de criar o corpo do método (se bem se recordam, a API foi criada na fase de desenho, mas os métodos estavam todos vazios, sem código). De certa forma, confirmou-se aquilo em que acredito: o peso de definir a API previamente não compensa os ganhos, na maior parte dos casos. O BUFD (Big Up-Front Design) não compensa, especialmente nos casos em que os requisitos são mais voláteis. É claro que sou parcial, mas é a minha convicção, baseada na minha experiência e na de projectos que acompanhei de fora.

Em segundo lugar, ainda me falta alguma prática. É um método muito diferente do habitual e que exige prática. Nomeadamente, sinto que os meus testes podem ser simplificados, ou seja, nalguns casos crio testes demasiado grandes, que verificam demasiadas coisas. Apesar disso, este é um ponto em que acho que estou bastante melhor agora do que há uns meses atrás. Seguir o mantra "Red, Green, Refactor" - criar o teste, fazê-lo passar o mais depressa possível, arrumar o código - exige prática e concentração. Sinto que ainda posso melhorar um bocado, especialmente na separação entre o Green e o Refactor. Nalgumas situações mais complexas, ainda tendo a misturar as duas coisas e é importante mantê-las separadas.

No entanto, os efeitos do TDD são dramáticos, algo que senti desde que comecei a praticá-lo. Mesmo quando ainda tinha muito pouca (ou nenhuma) experiência na prática, mas muita vontade de aprender, a sensação de liberdade e segurança é extraordinária (às vezes demasiada...). O TDD liberta-nos do constragimento que costuma agrilhoar o processo de desenvolvimento: o medo de mexer (If it ain't broke, don't fix it). Com o TDD o software fica realmente soft, como diz o Fowler ou o Beck, a sua manipulação torna-se possível e deixa de ser uma coisa rígida... a comparação da programação com a engenharia civil perde um pouco o sentido... ;)

Ao longo do processo de Construção o desenho do Sistema sofreu múltiplas alterações. Diversos conceitos, que estavam escondidos, apareceram e foram explicitados em objectos. O desenho final do Sistema é bastante melhor do que o inicial, algo que é muito raro acontecer com os métodos tradicionais. A liberdade de experimentar e moldar, com a segurança e disciplina do TDD, é algo que uma vez experimentado não se quer voltar a perder.

Sem o TDD conseguiria toda esta flexibilidade? Não, não e não. A qualidade do desenho decairia à medida que se ia dando uma marteladinha ali, outra acolá, "só mais este toque aqui". Expressões como "Sei que é uma martelada, mas agora não há tempo", é algo que tende a desaparecer de uma forma totalmente natural, sem esforço. Claro que nunca desaparece totalmente, afinal o mundo real é cheio de imperfeições.

O TDD liberta-nos da necessidade de testes funcionais (ou de aceitação)? Não, de maneira nenhuma. Os testes funcionais abordam um problema diferente. Os testes unitários orientam o Programador, ajudam este a seguir o caminho que pretende. Os testes de aceitação certificam que o Sistema faz o que o Cliente pretende. Podem ser duas coisas diferentes... mas práticas como realizar iterações de desenvolvimento muito curtas, de que falei no post anterior, garantem que a dessincronização entre Programador e Cliente é negligenciável.

No próximo post continuamos com a saga,  para não tornar o post demasiado grande e maçador...