c# - 了解为什么我们使用控制反转容器进行单元测试

Question

我目前正在考虑将 Ninject 合并到我的单元测试中。在浏览一些与早期问题相关的非常聪明的帖子时(What is Ninject and when do you use it?，http://martinfowler.com/articles/injection.html)；我想我得到了一些核心概念，但我正在为它的一些应用而苦苦挣扎。

大多数时候，当 IOC 容器被提及时，它与将它们合并到您的单元测试中有关。但是，从实际的角度来看，如果我还没有将它合并到我的实际代码库中，那么在我的单元测试中使用像 Ninject 这样的框架是否有意义？

以下面的例子为例(摘自 James Bender 的 C# 专业测试驱动开发:使用 TDD 开发真实世界的应用程序)

[TestFixture]
public class PersonServiceTests
{
    [Test]
    public void ShouldBeAbleToCallPersonServiceAndGetPerson()
    {
        var expected = new Person {Id = 1, FirstName = “John”, LastName = “Doe”};
        var kernel = new StandardKernel(new CoreModule());
        var personService = kernel.Get < PersonService > ();
        var actual = personService.GetPerson(expected.Id);
        Assert.AreEqual(expected.Id, actual.Id);
        Assert.AreEqual(expected.FirstName, actual.FirstName);
        Assert.AreEqual(expected.LastName, actual.LastName);
    }
}

使用 Ninject 编写我的测试如何改善我的生活(或继承我代码的任何可怜的开发人员)，而不是仅仅将我的测试编写为:

[TestFixture]
public class PersonServiceTests
{
    [Test]
    public void ShouldBeAbleToCallPersonServiceAndGetPerson()
    {
        var expected = new Person {Id = 1, FirstName = “John”, LastName = “Doe”};
        var personService = new PersonService();
        var actual = personService.GetPerson(expected.Id);
        Assert.AreEqual(expected.Id, actual.Id);
        Assert.AreEqual(expected.FirstName, actual.FirstName);
        Assert.AreEqual(expected.LastName, actual.LastName);
    }
}

当我将依赖倒置原则融入我的代码时；我将 IOC 容器的值(value)视为一种减少与我的类实例化相关的冗余/集中代码的方法(作为尊重依赖倒置原则的结果)。但是，如果我不想在我的代码中使用 IOC 容器，那么将 Ninject 之类的东西单独用作我的单元测试框架堆栈的一部分是否可行？

Answer 1

为什么要在测试中使用 DI 框架？您的对象图很难编写吗？

我个人认为你最好让测试明确地创建它们的依赖关系，因为这样注入(inject)模拟或 stub 将在测试中显式并且非常明显。

它还隐藏了有关创建复杂依赖层次结构的任何问题。在测试中创建所有对象意味着您将不得不感受到创建这些依赖项的痛苦，并且可能会激励您改进设计。

我不认为在这种情况下使用 DI 框架会给你带来任何好处，除了混淆你的测试所具有的依赖性。

集成测试可能是另一回事，但对于单元测试...