更新

是这样的，不是单元测试吗？它是集成测试吗？

[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。

顺便说一句：通过这样做，我发现了我的问题的根源，与我通过使用Web应用程序调试它的时间相比。

Answer 1

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

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

编辑＃2 （响应OP编辑）

当然，有可能在没有实际触及任何外部系统的情况下进行root-resolve测试，但仍然可能存在很多依赖关系，并且设置在真实对象上（如，不是假货/存根）。这是失败的许多潜在原因（我会说单元测试的数量太多了），并由开发人员来判断它属于哪种测试类别。

进行组件解析测试（与更小范围相关的解决方案）可能适用于单元测试，但是再一次 - 它可供开发人员判断，并且在很大程度上取决于对象在解决时的作用。大多数现代容器通常提供的不仅仅是简单的存储，应该考虑到这一点。

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

编辑＃1 （以回应有关的OP评论）

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

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

Answer 2

如果您真的想为IoC等基础设施代码编写单元测试来检查IoC实现是否正确，您可以查看IoC的单元测试源代码。

例如DotNet-s autofac IoC Unittests

关于你的问题的其他答案和评论（以及我在第一次运行中）也认为你想要编写一个自动测试，以确保你的组件在IoC正确接线的情况下。我们大多数人将这种测试称为集成测试而不是单元测试。

单元测试IoC容器本身

更新

2 个答案: