IoC 容器本身的单元测试

我认为以前没有人问过这个问题，尽管搜索这样的术语确实很困难单元测试ioc容器并且没有找到有关如何实现 IoC 以便执行单元测试的问题。

我想对 IoC 容器本身进行单元测试，基本上是因为有时我会遇到容器问题（就像应用程序的任何其他部分一样），并且仅通过调试来测试依赖项的解析非常麻烦。

如果我能为这些情况引入单元测试，我想这会省去我很多麻烦。

Update

这样的事情不是单元测试吗？这是集成测试吗？

[TestClass]
public class IoC
{
    private IWindsorContainer _container;

    [TestInitialize]
    public void TestInit()
    {
        _container = new WindsorContainer();
        _container.Install(new WindsorInstaller());
    }

    [TestMethod]
    public void ContainerShouldResolve_MembershipProvider()
    {
        ContainerShouldResolve<IMembershipProvider>();
    }

    public void ContainerShouldResolve<T>()
    {
        T result = _container.Resolve<T>();
        Assert.IsInstanceOfType(result, typeof(T));
    }
}

唯一真正的“非独立”参考是我必须连接的连接字符串app.config。另外：当试图解决PerWebRequest生活方式的组成部分我必须添加相关的httpModule, too.

顺便说一句：与使用 Web 应用程序进行调试相比，通过这样做，我在很短的时间内就找到了问题的根源。

这更多地落入集成测试类别。当解析时，您的组件注册可能会执行各种外部系统调用（数据库、文件系统、网络、服务...），这就是单元测试结束的地方。

您可以对此类（集成）测试执行的一种方法是简单地解析您的应用程序根类型。这可能并不完整（特别是当您的应用程序执行大量延迟加载时），但通常足以发现丢失的位。

Edit #2 （回应OP编辑）

当然，可能可以在不实际接触任何提到的外部系统的情况下进行根解析测试，但仍然可能存在大量依赖项接线和设置正在进行真实的物体（如，不是假货/存根）。这是许多潜在的失败原因（我想说对于单元测试来说甚至太多了）并且由开发人员来判断这属于哪个测试类别。

进行组件解析测试（涉及更小范围的解析）可能适合单元测试，但同样，这是由开发人员判断的，这在很大程度上取决于对象在解析时执行的操作。大多数现代容器通常提供的不仅仅是简单的存储，这一点应该考虑在内。

我想说的是，如果你说DaoModule你想验证它可以从容器中解析，当然，这个可能是单元测试。但如果解决你的DaoModule设置连接并查询数据库以查看它是否处于有效状态，您可能需要重新考虑此类测试的去向。

Edit #1 （回应有问题的OP评论）

我想设置一个测试，在其中配置容器，向其抛出抽象类型（或接口），并使其正确解析为预期类型。

基本上，您想验证您的容器是否正常工作？不要那样做。只需选择一个经过测试的容器，您就可以假设它可以完成其工作。如果您觉得需要对第三方组件进行单元测试，那么您确实应该选择不同的组件。