在使用IoC时,单元测试的策略应该是什么?

单元测试中不需要DI容器,因为依赖关系是通过框架生成的模拟对象提供的,例如 Rhino Mocks Moq . 例如,当您测试一个类时,它对某个接口有依赖关系,这个依赖关系通常是通过构造函数注入提供的。

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

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

ISomeDependentObject

[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);
}

对于单元测试来说,Ninject并不是必需的,但是它减少了我必须输入的代码量。我只需要指定一次(每个项目)如何实例化我的接口,而不是每次初始化被测试的类时都这样做。

为了节省编写新测试的时间,我用尽可能多的通用设置代码创建了测试夹具基类。这些类中的设置过程初始化假存储库,为测试用户创建一些测试数据和假身份。单元测试只初始化太特定而无法进入通用设置过程的数据。

我还在一些测试中模拟对象(而不是伪造),但我发现伪造数据存储库会导致更少的工作和更准确的测试。

例如,在使用存储库mock时,要检查被测方法是否正确地将所有更新提交到存储库,要比使用存储库fake时困难得多。

这是一个相当多的工作,以建立在一开始,但真的帮助我减少了大量的时间,节省了从长远来看。

阿尔索 Automocking 最小起订量或 Auto Mock Container

自动模拟允许您获取对象 要测试的类型 依赖项将自动模拟 (假设它们是接口)和 你需要你可以设置预期的

正如Darin已经指出的,如果有mock,就不需要使用DI(然而,DI还有一些其他的好处,首先包括减少代码中的依赖性,这使得代码更易于维护和长期扩展。)