2

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

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

如果我可以为这些案例引入单元测试，我认为它会为我省去很多麻烦。

更新

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

[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 应用程序调试它所花费的时间相比，我很快就发现了问题的根源。

4

2 回答 2

1

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

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

编辑#2 （响应 OP 编辑​​）

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

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

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

编辑＃1 （回应有问题的OP评论）

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

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

于 2012-04-21T15:54:22.963 回答
0

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

例如 DotNet-s autofac IoC 单元测试

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

于 2012-04-21T16:08:55.373 回答