Se TDD é sobre design, por que eu preciso? [fechadas]

Cada vez mais os gurus do TDD nos dizem que o TDD não é sobre testes, é sobre design . Então, eu conheço alguns desenvolvedores que criam um design realmente bom sem TDD. Eles deveriam praticar TDD então?

O TDD não apenas me ajuda a obter o melhor design final, mas também a chegar lá em menos tentativas.

Eu costumava ter duas ou três facadas em um problema antes de decidir qual design eu achava melhor. Agora, esse mesmo tempo é gasto escrevendo testes e concentrando minha mente no design correto. E, como um bônus, isso me deixa com um conjunto de testes repetíveis. Ganhar!

Dito isto, inevitavelmente haverá pessoas para quem o TDD não oferece nada. Contanto que eles ainda tenham testes automatizados e repetíveis no final, tudo bem.

O que esse guru de TDD em particular está realmente tentando dizer não é que o TDD é um processo de design (embora muitas pessoas infelizmente o tenham interpretado dessa maneira). A mensagem aqui é que o uso de um processo como o TDD, se você fizer certo , tenderá a melhorar seu design geral.

O conceito fundamental é muito mais antigo que o TDD; projetando para testabilidade . Se você seguir rigorosamente os princípios do SOLID , especialmente o Princípio de responsabilidade única , encontrará um código muito fácil de testar. Por outro lado, se você tende a ser um pouco mais desleixado em seu design, provavelmente encontrará o processo de escrever testes de unidade para forçá-lo a fazer isso com mais frequência, para evitar a frustração de (a) descobrir o que precisa ser feito. ser testado e (b) gastar mais tempo configurando dependências do que escrevendo os testes reais.

Você não tem que seguir TDD para obter os benefícios deste, mas não ajuda a escrever os testes cedo - de preferência logo após você implementar uma classe, se não antes ou durante. Se você esperar demais, corre o risco dos testes "sujos híbridos" de que o autor está falando, que não têm muito valor porque são frágeis e tendem a quebrar durante a refatoração inofensiva - sem mencionar o aumento a escala reprojeta um processo dolorosamente difícil.

Você não pode saber se está realmente projetando para testabilidade se não escrever testes, e "testes de recursos" aleatórios com apenas 15% de cobertura de código não contam.

É claro que você pode criar bons designs sem precisar escrever um único teste - mas você tem certeza de que são ótimos designs? Como você sabe, se você não está claramente especificado por testes? O teste descobre muitos problemas e, embora um processo de controle de qualidade possa encontrar erros visíveis, eles não descobrirão más decisões de design.

Resposta simplista vinda de alguém que se esforça para aprender TDD: Você não precisa , mas o principal benefício que isso oferece é, simplesmente, confiança : Confiança de que seu aplicativo funciona. Confiança de que os casos de uso são satisfeitos. Confiança de que sua lógica é correta para o módulo "Foobar". Confiança de que seu código está estruturado adequadamente para ser sustentável e extensível seis meses depois, quando o CEO quiser adicionar um novo recurso maluco sobre o qual ele leu. Confiança de que, quando seu aplicativo crescer, foram lançadas as bases para que a arquitetura não se desfaça ou exija montes de hacks confusos para julgar novos recursos.

Sei que o que foi dito acima soou um pouco evangélico, mas é assim que vejo os benefícios do TDD. Mesmo que você possa criar projetos bons, sólidos e bem arquitetados usando o TDD, força sua mão a fazer as coisas certas e, em seguida, prova que as coisas estão sendo feitas corretamente, e mais importante, fornece uma linha de base para manter as coisas certas. Pelo pouco que aprendi no TDD, usá-lo me forçou a limpar o código e a seguir os conceitos adequados de engenharia de software, onde, de outro modo, faria a "coisa mais rápida possível", que muitas vezes resultava em códigos "hackeados".

Só posso falar da minha experiência. Para mim, o TDD trouxe várias coisas que eu não tinha antes na minha caixa de ferramentas de hábitos de estilo de desenvolvimento. Embora, vale dizer novamente que TDD não é solução para tudo. Eu sempre tento separar a implementação pronta de exploração e produção. O TDD em fase de exploração não é absolutamente necessário e ainda está desacelerando. Por outro lado, para o código pronto para produção, ele traz vários benefícios que, a curto e longo prazo, são muito valiosos para a saúde mental dos desenvolvedores e o karma do projeto.

• O TDD me faz pensar antes de implementar, o que geralmente é uma prática muito boa que evita muitas soluções para disparar e esquecer
• Isso me faz pensar em pequenas porções do problema, forçando-me a separar a solução em pequenos pedaços que se encaixam.
• Isso me faz escrever um código muito dissociado, porque sempre que preciso stub / mock / fake algo que não se encaixa no problema, eu naturalmente ligo um "WTF, por que devo fazer isso se não preciso ser associado a ele" . E isso me faz perceber melhor as conexões entre as coisas.
• Ele fornece um conjunto de verificações facilmente executáveis ​​para o meu código, para que eu não precise passar pelo estilo doloroso "var_dump", "p", "pp", "echo" da depuração de código. Apenas informa o que está errado, quando está errado. E se eu ainda não tiver uma verificação, basta adicionar um teste simples para verificá-lo repetidamente.
• Isso me garante que meu código funcione se todos os testes forem aprovados antes da implantação. Então, em vez de comer minhas unhas, vou comer um bolo, beber café e aproveitar minhas tardes.
• Testes de alto nível são muito bons nos casos em que você precisa refatorar algo. Se meu módulo precisar fornecer alguma funcionalidade ao mundo externo e eu tiver desenvolvido testes funcionais / de integração / pepino para provar que está funcionando corretamente, serei muito corajoso em refatorar esse código. Várias vezes me deparei com o código que não tinha testes e precisava refatorá-lo. Nesse caso, havia dois caminhos a seguir na prática. 1) solte o código 2) pule as alterações e deixe como está.

Há uma coisa que o TDD não corrige. Se você não sabe como construir o que está construindo, o TDD não produzirá solução para você. Você precisa ter um "design" aproximado ou uma visão geral do problema e da solução. O TDD fará com que você apenas o implemente de maneira mais elegante e sustentável com o código de maior qualidade.

Por fim, prefiro pensar em termos de BDD que se apóiam nas práticas de TDD. O BDD me faz implementar soluções usando o vocabulário do domínio e fazer com que o software se encaixe melhor no problema.

Pode haver muitas maneiras de obter um ótimo design, e há inquestionavelmente muitas interpretações diferentes do que constitui "ótimo" - ou mesmo "bom". Eu suspeito que a maioria dos TDDers não concordaria com você sobre a definição - que, se analisássemos o código que você considera ótimo, consideraríamos menos do que ótimo. O TDD nos leva a algumas qualidades muito específicas, e essas qualidades raramente são encontradas no código não TDD.

A testabilidade, obviamente, é uma dessas qualidades e a principal. Métodos e classes extremamente pequenos são talvez uma sub-característica, e isso leva a uma excelente nomeação. Talvez você conheça programadores que alcançam essas qualidades sem fazer TDD, mas eu não.