UML vs TDD

Aqui estão os principais benefícios que as pessoas buscam com UML, e uma análise resumida de como é possível (ou não) obtê-los com Test-Driven Development (TDD):

Análise prévia do problema

Se você precisa explorar o que o sistema deve fazer exatamente, o que pode ser melhor do que trabalhar como se ele já existisse? Os testes em TDD permitem isso, e de quebra ainda permitem validar o que foi implementado posteriormente. Ponto para TDD neste quesito.

Resultado parcial: UML 0 x 1 TDD

Reutilização de código

Aqui as duas abordagens trabalham de maneira muito distintas. Enquanto em UML tentamos identificar os pontos de reutilização antes, em TDD você deixa que estes pontos apareçam através de duplicações no código, que são removidos e transformados em componentes reutilizáveis com apoio dos testes automatizados. Para não entrar numa discussão sobre BDUF x Agile por enquanto, vamos declarar um empate.

Resultado parcial: UML 1 x 2 TDD

Linguagem unificada para especificação de sistemas

Como o princípio do TDD é especificar o sistema através de testes executáveis, ainda não existe uma ferramenta genérica que seja aplicável para qualquer sistema. Isto se deve ao fato que a execução destes testes automatizados geralmente depende da tecnologia que o sistema utiliza.

Ferramentas como FitNesse fornecem uma linguagem única para escrever testes independente da tecnologia do sistema, porém ainda deixam a desejar no que trata da execução destes testes.

Já para sistemas web, no entanto, o Selenium já desponta como ferramenta que se aplica a qualquer sistema que trabalhe com apresentação em HTML (independente da linguagem utilizada no servidor), o que constitui um cenário bastante abrangente hoje em dia.

Em resumo, se o que você busca é uma linguagem genérica, UML leva uma certa vantagem.

Resultado parcial: UML 2 x 2 TDD

Aumento na qualidade

Ambas as abordagens (se bem utilizadas) apóiam a qualidade, mas nenhuma delas a garante. Então temos mais um empate.

Resultado parcial: UML 3 x 3 TDD

Ferramenta de aprendizado

Não existe diagrama que substitua o que é ver uma determinada parte do sistema funcionando. E com TDD é possível aprender tanto o que o sistema faz (testes funcionais ou de aceitação) quanto como ele funciona internamente (testes de integração, de unidade, de desempenho). Mais um ponto para TDD.

Resultado parcial: UML 3 x 4 TDD

Facilidade na manutenção

Fazer uma mudança no sistema em UML implica em atualizar os diagramas e aplicar estas mudanças no código. Em TDD mudanças são representadas por novos testes automatizados, enquanto os testes já existentes colaboram para analisar o impacto desta alteração no resto do sistema. A vantagem de TDD neste caso é que é possível ver se o sistema está 100% funcionando por inteiro, o tempo todo. Já com UML isso só pode ser feito manualmente ou com apoio de ferramentas de rastreabilidade.

Resultado final: UML 3 x 5 TDD

Conclusão

Quem esperava uma vitória fácil de TDD deve ter ficado decepcionado. A questão é que UML tem seu valor, ainda mais se considerarmos que a maioria dos softwares ainda é construída com ciclos em cascata ou espiral. A minha idéia aqui foi apenas apresentar uma alternativa ao uso de UML e levantar a questão: será que UML é a melhor solução?

A minha parte eu já fiz, lançando a questão. Agora só me resta esperar a resposta dos defensores da UML