Claro que sim.
TDD é uma atividade de design. O teste de unidade que você escreve serve basicamente para definir suas expectativas em relação ao código que você vai escrever. E, ao fazer isso, você pensa não só no nível da implementação do algoritmo, mas em um nível um pouco mais alto: no nível de design. TDD permite que você brinque e experimente diferentes possíveis designs, dando feedback rápido sobre o resultado obtido, até que você encontre o design ideal para aquela situação.
Ou seja, quando você faz TDD, você pensa exclusivamente em design e não em testes. É uma prática de suporte para design de software.
Mas… É claro que você precisa testar! Você não apaga os testes que você produziu usando TDD, óbvio. Mas muito provavelmente eles não testam todas as possibilidades possíveis. E é aí que outras técnicas entram em cena, e você pode encontrar muita informação sobre elas em [1][2].
Resumindo, use TDD quando você precisa trabalhar no design de determinada classe ou módulo. Quando você estiver satisfeito com design, é hora de testar! Aí você pode fazer test-first, test-last, ou que você preferir, mas teste de verdade!
[1] The Art of Software Testing – Myers
[2] Introdução ao Teste de Software – Maldonado, Delamaro, Jino
#1 by Fabrício Ferrari de Campos on 26/06/2010 - 23:45
Breve, claro e conciso. Muito bom!
Concordo 100%, e é bom deixar bem claro que TDD não é uma prática de Teste de Software e sim de desenvolvimento, mais precisamente de design (modelagem), como você disse no começo do post.
Parabéns pelo post e pelo bom esclarecimento!
#2 by Natan Costa Lima on 28/06/2010 - 21:31
Todas as pessoas que ensinam TDD deveriam deixar isto claro no começo. Um mal-entendido pode acabar com a imagem de TDD para
quem não tem experiência.
#3 by Adolfo Neto on 28/06/2010 - 21:34
É sempre necessário deixar claro isso. Por quê? Deve ser mesmo por causa do nome (test-driven development). E porque os testes que fazemos ao fazer TDD não deixam de ser testes, não é mesmo?