结合单元测试（模拟）和依赖注入框架

Question

可能的重复：
使用 IoC 进行单元测试

我认为我在理解单元测试和/或依赖注入正在工作。我使用 NUnit 和 Rhino Mocks 进行单元测试，并使用 Ninject 作为依赖注入框架。总的来说，我认为这两者是完美的——但不知何故，它似​​乎变得更加复杂和难以理解。

（我会尽力编一个好例子，以保持干净和简单。这是关于我的，骑自行车）。

1.) 没有 DI/单元测试：
如果不知道 DI 和单元测试，我的代码就会像这样 - 我会很高兴：

public class Person
{
    public void Travel()
    {
        Bike bike = new Bike();
        bike.Ride();
    }
}

public class Bike
{
    public void Ride()
    {
        Console.WriteLine("Riding a Bike");
    }
}

要骑自行车，我只需要： new Person().Travel();

2.) 使用 DI：
我不想要那种紧密耦合，所以我需要一个接口和一个 NinjectModule！我会有一些开销，但是只要代码易于阅读和理解就可以了。我将只传递修改后的 Person 类的代码，Bike 类不变：

public class Person
{
    IKernel kernel = new StandardKernel(new TransportationModule());
    public void Travel()
    {
        ITransportation transportation = kernel.Get<ITransportation>();
        transportation.Ride();
    }
}

我仍然可以骑自行车： new Person().Travel();

3.)考虑单元测试（无 DI）：
为了能够检查 Ride-Method 是否被正确调用，我需要一个模拟。据我所知，接口注入一般有两种方式：构造函数注入和Setter注入。我选择构造函数注入作为示例：

public class Person
{
    ITransportation transportation;

    public person(ITransportation transportation)
    {
        this.transportation = transportation;
    }

    public void Travel()
    {
        transportation.Ride();
    }
}

这一次，我需要传递自行车：new Person(new Bike()).Travel();

4.) 使用 DI 并准备单元测试
3 中的类。考虑单元测试（没有 DI） 无需修改即可完成工作，但我需要调用 new Person(kernel.Get());。通过这种方式，感觉我失去了 DI 的好处——Person 类可以调用 Travel，而无需任何耦合，也不需要知道交通是什么类型。另外，我认为这种形式缺乏示例 2 的很多可读性。

是这样完成的吗？或者还有其他更优雅的方式来实现依赖注入和单元测试（和模拟）的可能性？

（现在看来，这个例子实在是太糟糕了——大家应该知道他此刻乘坐的是什么交通工具……）

Answer 1

一般来说，我会尽量避免使用 IoC 容器进行单元测试 - 只需使用模拟和存根来传递依赖项。

您的问题始于场景 2：这不是 DI - 这是 服务定位器（反）模式。对于真正的依赖注入，您需要传入依赖项，最好是通过构造函数注入。

场景 3 看​​起来不错，这是 DI，通常也是您如何在隔离中测试您的类 - 传递您需要的依赖项。我很少发现需要使用完整的 DI 容器进行单元测试，因为每个被测试的类只有几个依赖项，每个依赖项都可以被存根或模拟来执行测试。

我什至认为，如果您需要一个 IoC 容器，那么您的测试可能不够细粒度，或者您有太多依赖项。在后一种情况下，一些重构可能是为了从您正在使用的两个或多个依赖项形成聚合类（当然，前提是存在任何语义连接）。这最终会将依赖项的数量降低到您满意的水平。这个最大数量每个人都不一样，我个人力求最多4个，至少一只手就能数出来，嘲讽也不是太大的负担。

反对在单元测试中使用 IoC 容器的最后一个也是关键的论点是行为测试：如果您不能完全控制依赖项，您如何确定被测类的行为符合您想要的方式？

可以说，您可以通过消除具有为某些操作设置标志的类型的所有依赖项来实现此目的，但这是一项艰巨的工作。使用 RhinoMocks 或 Moq 等模拟框架来验证是否使用您指定的参数调用某些方法要容易得多。为此，您需要模拟要验证调用的依赖项，IoC 容器在这里无法帮助您。

Answer 2

你对一些事情感到困惑。

实现 3 比 2 更好，因为您不需要在单元测试中设置 DI 框架。

因此，在测试第 3 点时，您将执行以下操作：

ITransportation transportationMock = MockRepository.GenerateStricktMock<ITransportation>();

// setup exceptations on your mock

var person = new Person(transportationMock);

DI 框架仅在生产代码中构建对象树时才需要。在您的测试代码中，您可以完全控制要测试的内容。当对类进行单元测试时，您会模拟所有依赖项。

如果您还想做一些集成测试，您可以将真正的自行车传递给您的人员类并进行测试。

完全隔离地测试类的想法是您可以控制每个代码路径。您可以使依赖项返回正确或不正确的值，甚至可以让它抛出异常。如果一切正常，并且您仅通过单元测试就获得了良好的代码覆盖率，那么您只需要进行一些更大的测试即可确保您的 DI 连接正确。

编写可测试代码的关键是将对象创建与业务逻辑分开。

Answer 3

我的 2 美分...

虽然第 2 点是依赖倒置原则 (DIP) 的示例，但它使用服务位置模式，而不是依赖注入。

您的第 3 点说明了依赖注入，其中 IoC 容器会在构建 Person 期间将依赖项（ITransportation）注入到构造函数中。

在您的真实应用程序和单元测试中，您也希望使用 IoC 容器来构建 Person（即不要直接 new Person）。如果您的单元测试框架支持，请使用服务定位器模式（kernel.Get();）或 DI（例如 Setter）。

然后，这将构建 Person 及其依赖项（即 ITransportation 的已配置具体类）并将其注入到 Person 中（显然，在单元测试中，您的 IoC 将为模拟/存根 ITransportation 配置）

最后，它是依赖项您想要 Mock，即 ITransportation，以便您可以测试 Person 的 Transport() 方法。

由于 Bike 没有依赖项，因此可以直接/独立地对其进行单元测试（除非将依赖项添加到 Bike，否则不需要模拟来测试 Bike.Ride()）。