Em uma discussão recente abordamos as implicações e conexões entre bom design e TDD.

Existem sistemas com bom design tanto que já foram criados com TDD quanto outros que não foi utilizado TDD desde o início. De qualquer maneira com o passar do tempo, um sistema legado passa a ter um deficit acumulado de design: o TDD pode minimizar os efeitos desse deficit a curto, médio e longo prazo, mas dificilmente zerá-lo.

Portanto, bom design não implica necessariamente em ter feito TDD?

E TDD, implica em bom design? Conheço projetos onde os desenvolvedores – conhecedores da tecnologia – utilizando TDD desde o início criam código com alta cobertura mas ainda com alto acoplamento: um design que ainda dificulta os testes e mudanças no design. O uso de TDD – bem usado – não implicou no design bom por outros motivos de como enfrentar questões de design, e não questões de como criar o código.

Além disso entram as questões de “o que deve ser testado”. Mesmo aplicando TDD, se pensamos que nem tudo precisa ser testado, será criado código que não implicará necessariamente em bom design.

Que práticas podemos usar para tentar garantir um bom design? Um design melhor?

Abraço

Creio que TDD é uma ferramenta muito importante para que se escreva código com um design, quase fundamental. Se bem utilizado, facilita a criação de testes simples e eficientes que evitam problemas de regressão.

Penso porém que TDD não é a única ferramenta para se criar um bom design, apesar de ariscar dizer que é fundamental para a maioria dos contextos. Bons conhecimentos de OO, seus principios, design patterns e boas práticas são também muito importantes.

Além disso creio que entender bem do negócio, e ter enteresse em aprender sobre o domínio, como sugere Domain Driven Design, pode ser determinante para alcançar melhores resultados. Construir modelos abstratos de alto nível, como sugere o livro Agile Modeling, também ajudam bastante.

Acredito que uma série de boas práticas e ferramentas bem aplicadas podem dar condições para um bom design, TDD é uma faz parte, mas é tudo.

Devo concordar com André faria, pois se a pessoa não sabe por exemplo o que é um padrão de projeto, ela não sabe usar bem oo, boas práticas de teste são fundamentais mas se seu conhecimento de oo básico ou oo avançado (padrões) é baixo, a escrita de teste fica dificultada.

Gulherme, creio que nem tudo precisa ser testado, mas as métricas dadas por uma ferramenta de cobertura, nem sempre indicam um bom design, TDD te coloca nos trilhos por servir de guia, um código que foi bem escrito mas não tem testes é pior do que um código ruim com testes, porque o código ruim com testes pode ser evolutivo e então se tornar um código bom.

Algo que ajuda a ter um bom design com certeza é o conhecimento que temos dos padrões e boas práticas, não saber por exemplo o que é um composite, um command ou melhor como usar os dois e como eles te ajudam a resolver seus problemas necessariamente implicará em um design inferior ao que conhece o padrão.

Portanto um código bom deve resumir flexibilidade, ter um baixo acoplamento, ter uma alta coesão e é muito além de tudo isso ter uma boa separação de conceitos.

Pra mim, TDD é uma ferramenta pra fazer design, mas não necessariamente pra fazer bom design. TDD garante bom design tanto quanto saber desenhar diagramas num quadro garantem bom design… ou seja, não garante.

Quem faz o bom design é o programador. Se o cara não tiver experiência, não souber reconhecer o que é bom e o que é ruim, não souber como melhorar o código, não adianta nada ele saber fazer TDD.

Do outro lado – dado que o cara tem essa experiência – TDD é uma boa ferramenta sim mas eu não acho que ela seja suficiente. Ou seja, é como o André disse, ele tem que saber princípios de OO, entender do domínio, etc.

Eu vejo duas vantagens que o TDD dá “quase” de graça: A necessidade de gerenciamento de dependências desde cedo. Vc é meio que obrigado a deixar suas dependências explícitas. Se não fizer, você não consegue escrever o teste; Faz com que os comportamentos da classe sejam invocados de forma mais natural. Porquê, de novo, se você complicar, você não testa!

Mas TDD é uma ferramenta que te dá feedback sobre o teu design; ele não faz o design por você. Nessa hora, entra a experiência e o conhecimento do programador. Se o programador não entender muito sobre boas práticas e design, muito provavelmente o feedback que o teste provê não servirá de nada; mas a parte boa é que o inverso também é verdadeiro: se ele realmente entender de design, o feedback será de grande valia!

Oi Mauricio, tudo bem?

Acho que essa vantagem das dependências está quando pensamos nos testes de unidade e acho importantissimo pois reforça mesmo. Mas nos testes de integração – e para quem faz somente testes de integração – não percebe que o acoplamento ainda está forte e o design deixa de ganhar nesse caso.

Já conectando com o segundo paragrafo, é o sinal que o TDD te deu do seu design no caso anterior: somente testes de integração são feitos é pois o design está forçando a fazer esse tipo de teste… realmente fecha o círculo.

E os resultados do estudo que você havia feito, tem um link público para compartilhar aqui?

Abraço!

Eu vejo TDD como uma técnica. E como técnica ele não vai resolver os seus problemas. Eu acho que ele melhora a sua escrita de código (Escrever o mais simples possível pra ficar “verde”), te “força” a usar um design voltado para testes (Isso depende de ser aplicado se o cara conhece ou não conhece) e te mostra futuramente problemas que poderam ocorrer (os testes serem quebrados por mudanças na design).

Aplicando TDD + DDD + Refactor tenho chegado a conclusão de que os códigos tem melhorado e o design também. Mas tudo isso foi obtido além da aplicação de TDD com DDD, além do estudo de várias formas melhores de programação.

Acredito que simplesmente TDD não té dará um bom design. Mas somando ele a técnicas de DDD + Refactor + Um bom conhecimento técnico acho que é o começo para um bom design.

Essa semana surgiu um post no Object Mentor sobre o assunto, comentando a adição de refactor no TDD:
http://blog.objectmentor.com/articles/2010/08/1…

Pareçe que todos convergimos

Bom, O Uncle Bob já deu a letra para uma resposta rápida da sua pergunta: “Habilidade, talento e conhecimentos continuam a ser necessários” ponto. O Koskela não deixa esquecer a essencia do TDD: “primariamente design”.

Juntando tudo isso, chego a conclusão que: TDD primariamente deveria te ajudar no design, e como técnica, requer alguma habilidade para ser executada com maior eficacia. Logo, não vai lhe garantir um bom design se o desenvolvedor não for eficiente suficiente para tal.

A técnica do TDD é baseada em práticas, entre elas o test-first (muito conhecido do XP), cuja consequencia é ir desenvolvendo o teste antes do código, para que seja criado somente o essencial ie. a porção de código para atender o seu requisito, num segundo passo, você passa a melhorar aquele código, aplicando a refatoração, a suite de testes é por conta da casa. Ao fim de tudo isso, espera-se classes coesas, testadas de forma unitária e com baixo acoplamento.

Por ser uma técnica de design, algumas pessoas já chamam de Design By Example, Specification by Example, para não gerar confusão na cabeça dos iniciantes (a palavra teste no TDD é muito danada, as pessoas acabam achando que TDD é sobre testes e por sorte ganha-se o design, mas é justamente o contrário) etc.

Para saber o que, como, quando testar… recomendo a leitura do bom artigo do Dan North (criador de BDD, que é uma técnica baseada em TDD para testes de aceitação, alguns chamam da evolução do TDD): http://blog.dannorth.net/introducing-bdd/

[]´s

follow me
@irobson

Definitivamente não. Não existe nenhuma fórmula para bom design. Acredito sim que TDD ajuda você a criar um bom design, principalmente por facilitar o refactoring e por você identificar code smells logo cedo. Mas não tem segredo, para um bom design vocé tem que ter bastante conhecimento de orientação a objetos, boas práticas e outras técnicas com DDD.

Eu já vi (e desenvolvi) várias aplicações com bom design sem testes. Acho que TDD só ficou bastante popular na nossa comunidade a poucos anos atras, mas os conceitos de Separation of Concerns, Layered Architecture, etc são mais bem difundidos e difundidos a mais tempo.

Oi Robson e Rubem,

Realmente não temos como fugir do bom conhecimento de design + alguma prática para reforçar a utilização do que acreditamos que seja bom, e nesse sentido TDD (e BDD) é a pratica que utilizamos.

Abraço