代码之家  ›  专栏  ›  技术社区  ›  Tomas Vana

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

  •  16
  • Tomas Vana  · 技术社区  · 15 年前

    我的问题是关于单元测试。我知道DI会让我在那里的生活变得更轻松,因为它让我有可能将类协作者的存根/模拟实现注入到被测试的类中。我已经用这个技巧写了几个测试,对我来说似乎很有意义。我不确定的是,我是否也应该在单元测试中使用IoC(在本例中是Windsor Castle)(可能以某种方式将其配置为针对我的特殊情况返回存根/模拟),还是最好在测试中手动连接所有依赖项。你认为什么样的做法对你有效?

    4 回复  |  直到 14 年前
        1
  •  21
  •   Darin Dimitrov    15 年前

    单元测试中不需要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);
    }
    
        2
  •  3
  •   Adrian Grigore    15 年前

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

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

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

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

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

        3
  •  2
  •   Russell Giddings    15 年前

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

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

        4
  •  0
  •   Péter Török    15 年前

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