Seguir o TDD leva inevitavelmente a DI?

14

Aprendi a fazer Test Driven Development (TDD), Injeção de Dependência (DI) e Inversão de Controle (IoC) ao mesmo tempo. Quando eu escrevo código usando TDD eu sempre acabo usando DI nos construtores da minha classe. Eu estou querendo saber se isso é por causa de como eu aprendi a fazer TDD, ou se isso é um efeito colateral natural do TDD.

Então, minha pergunta é a seguinte: Seguir os princípios de TDD e escrever testes de unidade que não dependem de serviços externos inevitavelmente levam a DI?

    
por Gilles 15.08.2012 / 16:55
fonte

5 respostas

19

Does following TDD and writing unit tests that do not depend on databases or external services inevitably lead to DI?

Para definições amplas de DI, sim. As classes não existem em um vácuo, então elas precisam ter suas dependências preenchidas de alguma forma. Às vezes, apenas fornecer um valor é bom. Às vezes você precisa fornecer uma simulação no construtor. Às vezes via contêineres IoC. Às vezes via acessor de teste privado. Está tudo injetando algo de teste na classe para que ele possa trabalhar isoladamente.

    
por 15.08.2012 / 17:05
fonte
9

Para pessoas que já sabem sobre DI, mas nunca viram o ponto, acho que o teste unitário quase invariavelmente leva ao uso de DI.

Se você não sabe sobre DI e está tentando escrever testes de unidade, algumas pessoas vão naturalmente reinventar o DI, algumas ficarão frustradas e eventualmente descobrirão DI por meio de pesquisa, mas você ficaria surpreso com que frequência simplesmente não ocorrerá a alguém que possa haver uma maneira melhor de arquitetar seu software para facilitar o teste de unidade. Essas pessoas descartam os testes unitários como intratáveis e desistem.

    
por 15.08.2012 / 18:13
fonte
8

O teste da unidade levará à DI (pois força você a criar unidades fracamente acopladas). TDD não necessariamente, já que o TDD também pode ser usado para criar testes camada por camada, em vez de testes unitários "verbatim". Veja este artigo

link

para uma explicação das diferenças.

    
por 15.08.2012 / 20:56
fonte
3

Sim e não: o TDD leva a escrever um código bem estruturado, o que leva ao DI.

Com isso quero dizer que o TDD geralmente envia o caminho certo com relação ao encapsulamento, SRP e reusabilidade. Não se trata apenas de fazer alguns testes em torno de seu código: trata-se de usar esses testes para melhorar o design. Se um objeto criar suas próprias dependências, ele estará dentro de um contexto específico dentro de um aplicativo específico e provavelmente será inserido no aplicativo em maior grau. DI é uma coisa boa, não apenas do ponto de vista do teste, mas também do ponto de vista da qualidade do código.

    
por 15.08.2012 / 18:08
fonte
0

Como já foi mencionado em outras respostas, o TDD não requer testes unit . Você pode também escrever testes funcionais / de integração ao fazer o TDD. Das várias maneiras de aplicar o TDD, a criação de testes de unidade seria a forma "falsa até você fazer" (veja o livro de Kent Beck para detalhes).

Quanto a "TDD inevitavelmente leva a DI", definitivamente não o faz. O que se precisa ao escrever testes unitários é isolar a unidade que está sendo testada a partir das implementações de suas dependências externas. E isso pode ser feito com a mesma facilidade ou sem DI. A melhor maneira, provavelmente, é usar uma ferramenta adequada de isolamento / zombaria.

    
por 31.01.2014 / 21:47
fonte