使用依赖注入进行单元测试的依赖打破技术

IOC 容器不在讨论范围内。他只是简单地提到了这些问题(事实上,他说国际奥委会不在这本书的范围之内,我不明白,而且是少数几个我可以批评这本书的地方之一)。不管怎样,撇开国际奥委会不谈,各种技术是:

1. 构造器注入
2. 财产注入
3. 软件工厂与静力学
5. 方法注入

好的,我会描述一下我不喜欢上面每种方法的地方。
构造器注入 -使初始化对象变得混乱和困难,特别是在必须传递大量依赖项的情况下。
2。 财产注入 -罗伊似乎喜欢这种技术,但这是我最不喜欢的。如果有很多依赖项,那么用户必须记住初始化类所需的每个依赖项。我认为这很容易出错,而且很混乱。使类很难为不熟悉它的人初始化。
软件工厂与静力学 -虽然我不认为这是一个糟糕的技术,我不喜欢依赖国家。我喜欢处理完全无状态的对象,但到目前为止我认为这是最好的技术。
四。 软件工厂与虚拟方法 -类似于上述技术,但允许您从类继承,并且只重写设置依赖项并将其更改为存根的函数。我的想法类似于3——它只是让试图找出单元测试失败原因的人感到有点困惑。
方法注入 -我只能说。。。为调用的每个方法传递每个依赖项。说得够多了。

我想到了另一种方法,我更喜欢上面列出的每一种方法。我一般不鼓励条件编译,但我认为在一些地方,你可以使用它轻轻的意义。我建议将设置测试依赖项的方法的名称标准化。例如:

.InitalizeDepForTesting(IFileSystem file, IDatabase data, IEventLog event, ...)

然后将上述语句包装在条件编译语句中:

#If DEBUG
      public void InitializeDepForTesting(...)
#endIf

因此,您的内部依赖项继续按原样工作,不需要更改。您还可以防止弄脏构造函数,并将所有依赖项与其他“东西”一起传递。在您的生产代码中没有任何变化,而且很容易一眼就看出您必须如何初始化对象以进行测试。你们都怎么想?