遵循TDD是否不可避免地导致DI？

我学会了同时进行测试驱动开发（TDD），依赖注入（DI）和控制反转（IoC）。当我使用TDD编写代码时，我总是最终在类的构造函数中使用DI。我想知道这是因为我学会了如何进行TDD，还是这是TDD的自然副作用。

所以我的问题是：遵循TDD原理和编写不依赖外部服务的单元测试是否不可避免地导致DI？

遵循TDD和编写不依赖于数据库或外部服务的单元测试是否不可避免地导致DI？

对于DI的广泛定义，可以。类不存在于真空中，因此需要以某种方式填充其依赖项。有时只提供一个值就可以了。有时您需要在构造函数中提供一个模拟。有时通过IoC容器。有时通过专用测试访问器。都是在类中注入一些测试内容，以便可以独立工作。

对于已经了解DI却从未了解过这一点的人们，我认为单元测试几乎总是会导致使用DI。

如果你不知道的DI，并试图写单元测试，一些人自然会重塑DI，有些人会感到沮丧，并最终通过研究发现DI，但你会惊奇地发现往往根本不会发生的人可能会有更好的方法来设计其软件，以使单元测试更加容易。这些人认为单元测试很棘手，并且放弃了。

单元测试将导致DI（因为它会迫使您创建松耦合的单元）。TDD不是必需的，因为TDD也可以用于逐层创建测试，而不是“ verbatim”单元测试。看这篇文章

http://stephenwalther.com/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx

解释差异。

是和否：TDD导致编写结构良好的代码，而该代码本身导致DI。

我的意思是，TDD通常会向您发送有关封装，SRP和可重用性的正确方法。这不仅涉及对代码进行一些测试；还涉及使用这些测试来充实更好的设计。如果一个对象创建了自己的依赖关系，那么它就生活在特定应用程序的特定上下文中，并且可能会更大程度地融入到应用程序中。DI不仅是从测试的角度，而且从代码质量的角度来看都是一件好事。

正如其他答案中已经指出的那样，TDD不需要单元测试。在进行TDD时，您也可以编写集成/功能测试。在应用TDD的几种方法中，创建单元测试将是“伪造直到完成”的方法（有关详细信息，请参见Kent Beck的书）。

至于“ TDD不可避免地导致DI”，那绝对不是。编写单元测试时，需要的是将要测试的单元与其外部依赖项的实现隔离开来。无论有没有DI，都可以轻松完成。最好的方法可能是使用适当的隔离/模拟工具。