O desenvolvimento orientado a testes me força a seguir o SOLID?

14

Eu ouço muito dos profissionais de TDD que uma das vantagens do TDD é que isso força os desenvolvedores a seguir princípios SOLID (Responsabilidade única, Aberto-fechado, Substituição de Liskov, Segregação de interface e Inversão de dependência). Mas, para mim, basta escrever alguns testes (teste de unidade principalmente) para entender que é importante seguir o SOLID (e, assim, criar uma arquitetura testável).

O TDD força os desenvolvedores a seguir o SOLID mais ativamente do que apenas escrever testes de unidade?

    
por SiberianGuy 01.10.2011 / 19:30
fonte

4 respostas

23

Primeiro de tudo, o TDD não estritamente força você a escrever o código SOLID. Você poderia fazer TDD e criar uma grande bagunça se quisesse.

Naturalmente, conhecer os princípios do SOLID ajuda, porque senão você pode acabar não tendo uma boa resposta para muitos dos seus problemas e, portanto, escrever códigos ruins acompanhados de testes ruins.

Se você já conhece os princípios do SOLID, o TDD incentivará você a pensar sobre eles e usá-los ativamente.

Dito isso, ele não cobre necessariamente todas as letras em SOLID , mas o encoraja e promove strongmente que você escreva, pelo menos parcialmente, o código SOLID, porque ele faz as consequências de não fazê-lo imediatamente visível e irritante.

Por exemplo:

  1. Você precisa escrever código desacoplado para poder zombar do que precisa. Isso suporta o Princípio de Inversão de Dependência .
  2. Você precisa escrever testes que sejam claros e curtos, para que você não precise alterar muito os testes (o que pode se tornar uma grande fonte de ruído de código se feito de outra forma). Isso suporta o Princípio de Responsabilidade Única .
  3. Isso pode ser discutido, mas o Princípio de Segregação de Interface permite que as classes dependam de interfaces mais leves que facilitam o acompanhamento e o entendimento do mocking, porque você não precisa perguntar "Por que não esses 5 métodos também foram ridicularizados? ", ou ainda mais importante, você não tem muita escolha ao decidir qual método deve ser burlado. Isso é bom quando você não quer realmente examinar todo o código da classe antes de testá-lo, e apenas usar tentativa e erro para obter uma compreensão básica de como ele funciona.

Aderir ao princípio Open / Closed também pode ajudar em testes que são escritos após o código, porque normalmente permite que você substitua as chamadas de serviço externo nas classes de teste que derivam das classes em teste. Em TDD, acredito que isso não é tão exigido quanto outros princípios, mas posso estar enganado.

Aderir à regra de substituição de Liskov é ótimo se você quiser minimizar as mudanças para que sua classe receba uma instância não suportada que implemente a mesma interface com tipagem estática, mas não é provável que ocorra em casos de teste apropriados, você geralmente não passará em nenhuma classe sob teste as implementações reais de suas dependências.

Mais importante ainda, os princípios do SOLID foram feitos para encorajá-lo a escrever um código mais limpo, mais compreensível e de fácil manutenção, assim como o TDD. Então, se você faz o TDD corretamente, e presta atenção em como seu código e seus testes parecem (e não é tão difícil porque você obtém feedback imediato, API e correção), você pode se preocupar menos com os princípios do SOLID, em geral. p>     

por 01.10.2011 / 21:02
fonte
9

Não

O TDD pode facilitar o acompanhamento de boas práticas por causa da contínua refatoração, mas não o força a seguir nenhum princípio. Tudo o que ele faz é garantir que o código que você escreve seja testado. Você pode seguir os princípios que desejar ao escrever o código para satisfazer o teste; ou nenhum princípio em tudo.

    
por 01.10.2011 / 19:49
fonte
2

Meu entendimento dos Princípios SOLID expandiu-se em uma ordem de magnitude quando comecei a fazer TDD. Assim que comecei a pensar em como simular dependências, percebi que praticamente todos os componentes da base de código tinham uma potencial implementação alternativa. E quanto mais fácil é testar uma API pública simples.

Também forneceu um entendimento muito mais strong da maioria dos padrões de design. Especialmente o padrão de estratégia.

    
por 03.10.2011 / 15:19
fonte
0

Sim : O TDD é principalmente uma boa técnica de projeto (e apenas secundária, uma técnica de teste). Isso ajuda muito a alcançar os princípios sólidos, embora exemplos (patológicos) de TDD com muitos cheiros de código ainda sejam possíveis.

A conexão entre o TDD e os princípios sólidos é contestada (com a conclusão acima) em este grande podcast hanselminute chamado" Test Driven Development é Design - A última palavra no TDD ".

    
por 01.10.2011 / 21:39
fonte