O desenvolvimento orientado a testes me obriga a seguir o SOLID?

15

Eu ouço muito dos profissionais do TDD que uma das vantagens do TDD é que ele força os desenvolvedores a seguir os princípios do SOLID (responsabilidade única, aberto-fechado, substituição de Liskov, segregação de interface e inversão de dependência). Mas, quanto a mim, basta escrever alguns testes (principalmente teste de unidade) 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?

unit-testing tdd solid

— SiberianGuy
fonte

1

O TDD é principalmente sobre forçar os desenvolvedores a escrever testes. Portanto, se você diz que escrever testes de unidade faz com que você escreva código SOLID, acho que isso diz que o TDD obriga a escrever código SOLID. Isso se baseia apenas no que você disse e não reflete com precisão minha opinião, que você pode ver na minha resposta.

— Yam Marcovic

1

Inhame: Eu discordo, TDD não é sobre escrever testes de unidade. O TDD trata de chegar a uma solução minimamente complexa e correta para o problema em questão. Testes são apenas um subproduto do processo

— Amit Wadhwa

TDD por definição é sobre escrever testes antes do código. Teoricamente, você pode criar uma solução minimamente complexa e correta, mesmo sem testes. Os testes simplesmente fornecem feedback instantâneo e reconhecimento de regressão. Como ainda é possível criar uma solução complexa com testes, o TDD não se trata de criar soluções minimamente complexas por si só. É o oposto do que você disse. Soluções elegantes são um subproduto do procedimento, e não o contrário.

— Yam Marcovic

24

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

Obviamente, conhecer os princípios do SOLID ajuda, porque, caso contrário, você pode simplesmente não ter uma boa resposta para muitos dos seus problemas e, portanto, escrever um código incorreto acompanhado de testes ruins.

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

Dito isso, ele não necessariamente cobre todas as letras do SOLID , mas incentiva e promove fortemente a você escrever pelo menos parcialmente o código do SOLID, pois torna as conseqüências de não fazê-lo imediatamente visíveis e irritantes.

Por exemplo:

Você precisa escrever um código dissociado para simular o que precisa. Isso suporta o princípio de inversão de dependência .
Você precisa escrever testes claros e curtos para não precisar mudar muito nos testes (que podem se tornar uma grande fonte de ruído de código, caso contrário). Isso suporta o princípio de responsabilidade única .
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 a compreensão da zombaria, porque você não precisa perguntar "Por que esses 5 métodos também não foram zombados?", Ou ainda mais importante, você não tem muitas opções ao decidir qual método simular. Isso é bom quando você realmente não deseja revisar todo o código da classe antes de testá-lo e apenas usar tentativa e erro para obter um entendimento básico de como funciona.

A adesão ao princípio Aberto / Fechado pode ajudar os testes escritos após o código, porque geralmente permite substituir chamadas de serviço externas em classes de teste derivadas das classes em teste. No TDD, acredito que isso não é tão necessário quanto outros princípios, mas posso estar enganado.

A adesão à regra de substituição de Liskov é ótima se você deseja minimizar as alterações para que sua classe receba uma instância não suportada que apenas implementa a mesma interface de tipo estaticamente, mas não é provável que isso aconteça em casos de teste adequados, porque você geralmente não passa em nenhuma classe em teste as implementações reais de suas dependências.

Mais importante, os princípios do SOLID foram criados para incentivá-lo a escrever código mais limpo, mais compreensível e sustentável, assim como o TDD. Portanto, se você faz o TDD corretamente e presta atenção à aparência do seu código e dos seus testes (e não é tão difícil porque você obtém feedback imediato, API e precisão), você pode se preocupar menos com os princípios do SOLID, em geral.

— Yam Marcovic
fonte

Além disso, a menos que você siga a opção Aberto / fechado e a substituição de Liskov, suas zombarias serão quebradas mais tarde. Portanto, mesmo que o TDD possa não ajudá-lo a aplicar o OCP e o LSP, os testes criados informarão quando você o quebrar. Mais um efeito dos testes em geral, mas ainda vale a pena mencionar.

— Jonas Schubert Erlandsson

9

Não

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

— dietbuddha
fonte

2

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

Também forneceu uma compreensão muito mais forte da maioria dos padrões de design. Especialmente o padrão de estratégia.

— Heath Lilley
fonte

0

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

A conexão entre o TDD e os princípios sólidos é discutida (com a conclusão acima) neste excelente podcast em minutos, chamado "Desenvolvimento Orientado a Testes é Design - A Última Palavra no TDD" .

— DaveFar
fonte