unit-testing - 使用依赖 Inj 进行单元测试的依赖破坏技术

Question

目前正在阅读 Roy Osherove 的“单元测试的艺术”。我大约读了一半，到目前为止，这是一本很棒的书。我要请大家离开IOC容器不在此讨论范围内。他只是简单地提到了它们(实际上说国际奥委会不在我不理解的书的范围内，这是我可以批评这本书的少数几个地方之一)。不管怎样，抛开 IOC，各种技术是:

1. 构造函数注入(inject)
2. 属性注入(inject)
3. 软件工厂和静态
4. 软件工厂和虚拟方法
5. 方法注入(inject)
6. 列表项

好的，我将描述我不喜欢上面每种方法的地方。
1. 构造函数注入(inject) - 使初始化对象变得困惑和困难，尤其是当您必须传递大量依赖项时。
2. Property Injection - Roy 似乎喜欢这种技术，但它是我最不喜欢的。如果您有一堆依赖项，那么用户必须记住初始化该类所需的每个依赖项。我会说这是容易出错和困惑的。使不熟悉它的人很难初始化该类。
3. Software Factory and Statics - 虽然我不认为技术有什么坏处，但我不喜欢依赖状态。我喜欢处理完全无状态的对象，但到目前为止我认为这是最好的技术。
4. Software Factories and Virtual Methods - 与上述技术类似，但允许您从类继承并且仅覆盖设置依赖项的函数并将其更改为 stub 。我的想法与 3 类似——它只是让试图找出单元测试失败原因的人有点太困惑了。
5. 方法注入(inject) - 我只能说 ewwwwwww ... 为您调用的每个方法传递每个依赖项。说的够多了。

我想到了另一种比上面列出的所有方法都更喜欢的方法。我通常不鼓励条件编译，但我认为在一些你轻轻使用它的地方它是有意义的。我的建议是标准化一个方法的名称，该方法设置您的测试依赖项。例如:

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

然后将上面的语句包裹在条件编译语句中:

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

因此您的内部依赖项将继续按原样工作，不需要更改。您还可以防止弄乱构造函数并将所有依赖项与一堆其他“东西”一起传递。就您的生产代码而言，没有任何变化，一眼就能看出您必须如何初始化对象以进行测试。大家怎么看？

Answer 1

构造注入(inject)是更清晰的选择，因为它清楚地建立了您拥有的依赖关系。如果它们太多且令人困惑，则可能表明您的设计存在问题。