对IoC容器本身进行单元测试 [英] Unit Testing the IoC container itself

问题描述

我不认为这是以前要问的，尽管很难搜索诸如 unit test ioc container 之类的术语，并且找不到有关如何实施IoC以便执行单元测试的问题

I don't think this was asked before, although it's really hard to search for a term like unit test ioc container and not find a question about how to implement IoC in order to perform unit tests.

我想对IoC容器本身进行单元测试，基本上是因为有时我会遇到容器问题(就像应用程序的任何其他部分一样)，并且仅调试就很难测试依赖项的解析.

I would like to have unit tests against the IoC container itself basically because sometimes I have issues with the container (like you could with any other part of an application), and it's pretty troublesome to test the resolution of dependencies merely debugging.

如果我可以针对这些情况引入单元测试，我认为这将为我省去很多麻烦.

If I could introduce unit tests for these cases, I think it would save me a lot of trouble.

是这样的东西，不是单元测试吗?是集成测试吗?

Is something like this, not an Unit Test? Is it an integration test?

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

The only real "not self-contained" reference is a connection string I had to wire into app.config. Also: when trying to resolve PerWebRequest lifestyle components I had to add the related httpModule, too.

顺便说一句:与使用Web应用程序调试它所花费的时间相比，通过这种方式，我很快就发现了问题的根源.

By the way: by doing this I found out the source of my issue in little time compared to what it was taking me to debug it through using the web application.

推荐答案

这更多地属于集成测试类别.解决后，您的组件注册可能会进行各种外部系统调用(数据库，文件系统，网络，服务...)，这就是单元测试的结束.

This falls more into integration testing category. Your components registration might do all kinds of external systems calls (database, file system, network, services ...) when resolved, and this is where unit testing ends.

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

One approach you can do to this kind of (integration) testing, is to simply resolve your application root type. This might not be complete (especially when your application does large bits of lazy loading), but is often good enough to spot missing bits.

编辑#2 (响应OP编辑)

当然，可以在不实际接触任何外部系统的情况下进行root-resolve测试，但是仍然可能存在许多依赖关系，它们的连接和设置对真实对象进行(如，而不是假货/存根).这是失败的许多潜在原因(对于单元测试，我想说的太多了)，并且要由开发人员来判断这属于哪种测试类别.

Of course, it might be possible to do root-resolve test without actually touching any external systems mentioned, but there still might be lot of dependencies wiring and setting up going on real objects (as in, not fakes/stubs). This is many potential reasons to fail (I'd say even too many for unit test) and is up to developer to judge what testing category this falls into.

进行组件解析测试(与较小范围相关的解析)可能适合单元测试，但是再一次-由开发人员判断，它很大程度上取决于对象对解析的处理方式.大多数现代容器通常提供的不仅仅是简单的存储，还应考虑到这一点.

Doing component-resolve test (resolve that relates to much smaller scope) might be fine for unit test, but once again - it's for developer to judge and it largely depends on what the objects do upon resolve. Most modern containers usually offer more than simple storage and this should be taken into account.

我要说的是，如果您说过DaoModule，并且要验证它可以从容器中解决，请确定，此可能是单元测试.但是，如果解析您的DaoModule设置连接并查询数据库以查看其是否处于有效状态，则可能需要重新考虑这种测试的去向.

What I'm trying to say is, if you have say DaoModule and you want to verify it can be resolved from container, sure, this might be an unit test. But if resolving your DaoModule setups connection and queries DB to see if it is in valid state, you probably need to reconsider where such test would go.

编辑#1 (响应正在讨论的OP评论)

我想在配置容器的地方进行测试，向其抛出抽象类型(或接口)，然后将其正确解析为期望的类型.

I want to set up a test where I configure the container, throw an abstract type (or interface) at it, and have it correctly resolve to an expected type.

基本上，您想验证您的容器是否正常工作? 不要这样做.只需选择一个经过测试的容器，您就可以假定它可以完成其工作.如果您需要对第三方组件进行单元测试，那么您真的应该选择其他组件.

Basically, you want to verify whether your container works? Don't do that. Simply pick a container that is tested and you can assume it can do its job. If you feel the need to unit test your 3rd party components, you really should be choosing different ones.

这篇关于对IoC容器本身进行单元测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！