TDD和DI:依赖注入变得麻烦

在云计算领域，TDD（测试驱动开发）和DI（依赖注入）是两个重要的概念，它们在软件开发过程中起到了关键作用。

TDD是一种软件开发方法，它要求开发人员在编写代码之前先编写测试用例。这种方法可以确保代码的质量和可靠性，同时也可以帮助开发人员更好地理解需求和设计。在TDD中，开发人员需要遵循红绿灯原则，即先编写失败的测试用例（红色），然后编写通过测试的代码（绿色），最后重构代码。

DI是一种设计模式，它可以帮助开发人员减少代码之间的耦合，提高代码的可维护性和可扩展性。在DI中，开发人员可以通过依赖注入容器来管理对象之间的依赖关系，从而降低代码的复杂度。DI可以分为构造函数注入、属性注入和方法注入三种方式。

TDD和DI的结合使用可以帮助开发人员更好地管理代码，提高代码的质量和可维护性。例如，在TDD中使用DI可以帮助开发人员更好地管理代码之间的依赖关系，从而提高代码的可测试性和可维护性。

推荐的腾讯云相关产品和产品介绍链接地址：

页面内容是否对你有帮助？

有帮助

没帮助

TDD和DI:依赖注入变得很麻烦

tdd、dependency-injection

C#、nUnit和Rhino Mock，如果它们被证明是适用的。当我试图围绕一个复杂的函数进行测试时，我对TDD的探索还在继续。假设我正在编写一个表单，该表单在保存时还必须在form...answers中保存依赖对象，以形成问题、附件和“日志”条目(如"blahblah updated the form“)。这意味着为了完全测试表单的save函数及其所有依赖项，我必须注入5到6个数据提供程序来测试这一个函数，并确保所有内容都以正确的方式和顺序启动。在为表单对象编写多个链式构造

浏览 2提问于2009-03-03得票数 9

回答已采纳

1回答

控制反转会导致副作用吗？

oop、dependency-injection、inversion-of-control、encapsulation

然而，与此同时，IoC的一些大优点是松耦合/模块化，以及测试驱动设计使得单元测试变得更加容易(我认为测试驱动设计确实在行业中推动了IoC )。这是我反对IoC的理由。如果注入的类型是不可变的和纯的，那么IoC是可以接受的，例如原始类型。然而，如果它们是不纯的，并且可以修改程序的状态或保持自己的状态，那么很容易发生副作用。它试图为注入的IFileSearcher上的播放列表设置正确的搜索路径，但该类的用户覆盖了该路径。现在，当他们试图在播放列表中查找歌曲时，结果是不正确的。我认为简单的、功能性的答案是只编写纯函数

浏览 22提问于2021-10-01得票数 1

4回答

遵循TDD必然会导致DI吗？

tdd、dependency-injection、inversion-of-control

我学会了同时进行测试驱动开发(TDD)、依赖注入(DI)和反向控制(IoC)。当我使用TDD编写代码时，我总是在类的构造函数中使用DI。我想知道这是因为我是如何学会做TDD的，还是这是TDD的自然副作用。因此，我的问题是:遵循TDD原则和编写不依赖于外部服务的单元测试是否不可避免地导致DI？

浏览 0提问于2012-08-15得票数 14

回答已采纳

3回答

测试驱动开发(TDD)确保依赖注入(DI)？

dependency-injection、tdd

TDD能帮助确保DI吗？或者是相反的情况(TDD需要DI)。

浏览 10提问于2013-12-06得票数 3

回答已采纳

3回答

适用于TDD和依赖项注入的有效Java项目1

java、dependency-injection、tdd、effective-java

我一直在阅读有效的Java，对于第一项“使用静态工厂方法而不是构造函数”，我对TDD和依赖项注入有一些关注。该项目指出，您应该避免使用公共/受保护/默认构造函数，并使用静态工厂公开它。但是，我认为约书亚错过了TDD的缺点，因为代码中有静态工厂会导致紧密耦合，您不能模拟使用它的类。我们将无法模拟具有静态工厂的类。因此，它阻碍了测试驱动的开发。第二点，我认为他忽略了在今天的企业开发中，大多数应用程序使用一个或另一个依赖注入容器。所以，当我们可以使用<e

浏览 4提问于2010-06-25得票数 8

3回答

应该注入哪些依赖项？

dependency-injection

在使用依赖项注入时，您要注入哪些依赖项？我以前注入了所有依赖项，但是在执行TDD时发现通常有两种依赖类型：public ClassWithExternalDependen

浏览 1提问于2010-11-09得票数 6

1回答

放弃DI使用BDD和集成测试

scala、design-patterns、dependency-injection

我发现在不严格遵循TDD的情况下使用依赖注入是无用的和额外的工作。当我使用DI创建应用程序时，它会导致我有多个逻辑层(存储库、服务(业务)、实体、模型等)。由于我没有严格遵循TDD，我发现这些层大部分时间都是无用的和冗长的！现在，使用Scala和Play框架，我可以比以前更容易地使用BDD和集成测试(我是迁移到Scala/Play的C#/.NET开发人员)。所以，放弃DI，坚持使用某种DDD，转而

浏览 2提问于2013-10-04得票数 1

回答已采纳

1回答

依赖反转与依赖注入与控制反转

java、spring、spring-boot、dependency-injection、inversion-of-control

我试图找到关于依赖反转、DI和IoC之间的区别的正确解释，并阅读了许多文章来理解这种差异，如以下所示：那么，你能简单地解释一下依赖反转、依赖注入和控制反转之间的区别吗？

浏览 7提问于2022-11-19得票数 0

2回答

MVC与依赖注入

model-view-controller、dependency-injection

任何人都可以总结或列出每个层的类型，如果考虑到依赖注入，那么MVC类型设计中有哪些层呢？我不讨厌读书，但我已经有很多书要读了(在家3本，工作1本，点菜3本，大学1本)。这两种方法都有响亮的支持者，但似乎在总体设计上存在冲突。

浏览 0提问于2009-10-25得票数 1

回答已采纳

1回答

将依赖注入类与容器传递到应用程序启动WinForm中

winforms、dependency-injection、ioc-container、n-tier-architecture、compositionroot

我正在开发一个WinForms应用程序，它被配置为典型的3层UI、BLL和DAL。我创建了一个单独的项目作为启动项目。还创建了另一个项目，作为一个自制的依赖注入容器，目的是执行所有的依赖注入设置。自制的依赖注入容器由启动项目实例化，然后将实例化的对象传递给第一个WinForm。自制的依赖注入容器实现如下所示：{ public BLL.DataServic

浏览 1提问于2015-12-17得票数 1

1回答

使用-工厂模式与依赖项注入

design、dependency-injection、spring、factory

更多的是关于何时使用依赖注入与工厂的关系。浸膏：它是一种创建模式，用于生成类的依赖项。它还提供松散耦合，因为类不再直接创建其依赖项。在我看来，在大多数情况下，可以使用DI注入依赖项，而工厂可以完全排除在外。我一直在使用Spring (到现在为止已经有一年了)，大多数情况下，类需要1到2个特定的<e

浏览 0提问于2015-08-16得票数 6

回答已采纳

2回答

具有分层体系结构的TDD，而只有单元测试域逻辑

unit-testing、domain-driven-design、tdd

在这种情况下，是否有可能和合理地进行TDD？(所有业务逻辑类都通过带有构造函数注入依赖项的DI消费其他类)

浏览 0提问于2018-07-04得票数 1

7回答

TDD/测试负担太多了吗？

testing、agile、tdd、bdd

首先，我是敏捷和测试的追随者. 最近，我讨论了如何在当前团队没有在任何级别上进行单元测试的产品重写上执行TDD，并且可能从未听说过依赖注入技术或测试模式/设计等(我们甚至不会使用干净的代码)。此外，由于它是一个前端应用程序(不是基于web的应用程序)，添加测试是没有意义的，因为业务驱动程序的变化(当然它们意味着改进)，测试将变得过时，将来进入该项目的其他开发人员将不再维护它们，成为他们修复的负担我可以理解，在一个目前没有任何测试经验的团队中，TDD听起来不太好，但我在本例中的论

浏览 0提问于2011-01-31得票数 24

回答已采纳

2回答

构造函数注入(DI)相对于静态工厂的横切关注点？

c#、design-patterns、dependency-injection、factory、cross-cutting-concerns

我注意到的是，在某些类中，如果使用IoC注入模块，它们往往会完全破坏构造函数。)} 对于构造函数过度注入的通常情况，我倾向于将关注点折射到构建块中，这些块紧密地对应在一起，因此在类中得到的依赖更少。然而，这是不可能的交叉概念。

浏览 2提问于2014-08-11得票数 8

回答已采纳

1回答

AutoFixture与私有财产

c#、autofixture

如果我将MyService依赖项公开为public，则下面的设置工作良好。

浏览 6提问于2014-03-28得票数 14

回答已采纳

2回答

Symfony DI Container原则2

symfony、dependency-injection、doctrine-orm

我正在做一个利用Doctrine 2的Zend Framework项目，我试图让Symfony的DI容器也能与这个项目一起工作，但我遇到了麻烦。假设我有一个类"Foo“，它需要注入两个实例。我可以设置一个Symfony DI容器，没有问题，它可以用注入的依赖项为我获取一个新的"Foo“。太棒了！但是现在如果我想让"Foo“成为Doctrine实体呢？当我将实体插入到DB中时，一切都很好，因为我可以从DI容器中获取一个新的实体，并简单地持久化

浏览 0提问于2011-03-14得票数 2

回答已采纳

3回答

PHP 5.3中的依赖注入

php、dependency-injection

我正在尝试整理一个应用程序，并且已经手动进行了一段时间的构造器依赖注入。我正在寻找一个积极开发和维护的DI容器。我发现Crafty是一种替代方案，它可以通过XML、YAML、数组或编程将依赖项连接在一起。 DI容器不应该与一个成熟的框架紧密耦合，我们正在寻找简单和可插拔的东西，并尽可能减少麻烦。

浏览 1提问于2010-12-20得票数 4

回答已采纳

1回答

在带有(Out) DI容器的Android中适当的依赖项注入(Dagger 1)

java、android、dependency-injection、inversion-of-control、dagger

然而，我开始更多地思考依赖注入的“真正精神”，并发现更多的博客文章/意见解释了这个概念，并实际上建议使用“构造器注入”，并将其他人(字段和setter注入)标记为“反模式”。我确实通过DI框架了解到他们对字段和setter注入的关注，因为前者没有显式显示对象的依赖性，而后者也没有严格地“要求”依赖。然而，一些人强烈认为，依赖注入的唯一是构造函数注入。为了

浏览 2提问于2015-04-16得票数 3

回答已采纳

2回答