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

在读完有关依赖注入和 IoC 的所有内容后，我决定尝试在我们的应用程序中使用 Windsor Container（它是一个 50K LOC 多层 Web 应用程序，所以我希望它不是一个矫枉过正的东西）。我使用了一个简单的静态类来包装容器，并在启动应用程序时初始化它，目前效果很好。

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

在单元测试中不需要 DI 容器，因为依赖项是通过框架生成的模拟对象提供的，例如犀牛模拟 http://www.ayende.com/projects/rhino-mocks.aspx or Moq http://code.google.com/p/moq/。因此，例如，当您测试一个依赖于某个接口的类时，这种依赖关系通常是通过构造函数注入提供的。

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

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

在您的应用程序中，您将使用 DI 框架来传递一些实际的实现ISomeDependentObject在构造函数中，它本身可能依赖于其他对象，而在单元测试中，您创建一个模拟对象，因为您只想单独测试此类。 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);
}