使用IoC时，单元测试的策略应该是什么？ [英] What should be the strategy of unit testing when using IoC?

问题描述

在我了解了有关依赖注入和IoC的所有知识之后，我决定尝试在我们的应用程序（这是一个5万个LOC多层网络应用程序，因此不希望它过于矫健）中使用Windsor Container。我使用了一个简单的静态类来包装容器，并在启动应用程序时对其进行了初始化，目前效果还不错。

After all what I have read about Dependency Injection and IoC I have decided to try to use Windsor Container within our application (it's a 50K LOC multi-layer web app, so I hope it's not an overkill there). I have used a simple static class for wrapping the container and I initialize it when starting the app, which works quite fine for now.

我的问题是关于单元测试的。我知道DI将使我有可能将类协作者的存根/模拟实现注入被测类，从而使我的生活更加轻松。我已经使用这种技术编写了一些测试，这对我来说似乎很有意义。我不确定的是我是否应该在单元测试中使用IoC（在本例中为Windsor Castle）（可能以某种方式将其配置为在特殊情况下返回存根/模拟）还是连接所有依赖关系更好在测试中手动进行。您认为如何？什么做法对您有用？

My question is about unit testing. I know that DI is going to make my life much easier there by giving me the possibility of injecting stub / mock implementations of class collaborators to the class under test. I have already written a couple of tests using this technique and it seems to make sense for me. What I am not sure about is whether I should be using IoC (in this case Windsor Castle) also in unit tests (probably somehow configure it to return stubs / mocks for my special cases) or is it better to wire-up all the dependencies manually in the tests. What do you think and what practice has worked for you ?

推荐答案

在单元测试中不需要DI容器，因为依赖项是通过使用诸如或最低订量。因此，例如，当您测试一个在某个接口上具有依赖性的类时，通常通过构造函数注入来提供这种依赖性。

You don't need DI container in unit tests because dependencies are provided through mock objects generated with frameworks such as Rhino Mocks or Moq. So for example when you are testing a class that has a dependency on some interface this dependency is usually provided through constructor injection.

public class SomeClassToTest
{
    private readonly ISomeDependentObject _dep;
    public SomeClassToTest(ISomeDependentObject dep)
    {
        _dep = dep;
    }

    public int SomeMethodToTest()
    {
        return _dep.Method1() + _dep.Method2();
    }
}

在您的应用程序中，您将使用DI框架来传递 ISomeDependentObject 在构造函数中的某些实际实现本身可能对其他对象具有依赖性，而在单元测试中创建模拟对象是因为您只想单独测试该类。犀牛Mo的示例：

In your application you will use a DI framework to pass some real implementation of ISomeDependentObject in the constructor which could itself have dependencies on other objects while in a unit test you create a mock object because you only want to test this class in isolation. Example with Rhino Mocks:

[TestMethod]
public void SomeClassToTest_SomeMethodToTest()
{
    // arrange
    var depStub = MockRepository.CreateStub<ISomeDependentObject>();
    var sut = new SomeClassToTest(depStub);
    depStub.Stub(x => x.Method1()).Return(1);
    depStub.Stub(x => x.Method2()).Return(2);

    // act
    var actual = sut.SomeMethodToTest();

    // assert
    Assert.AreEqual(3, actual);
}

这篇关于使用IoC时，单元测试的策略应该是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！