组合根是否需要单元测试？

Question

我试图找到答案,但似乎没有直接讨论过很多.我有一个我的应用程序的组合根,我创建一个DI容器并在那里注册所有内容,然后解决所有依赖项所需的顶级类.由于这一切都在内部发生 - 因此很难对组合根进行单元测试.你可以做虚拟方法,受保护的字段等等,但我不是为了能够进行单元测试而引入这些东西的忠实粉丝.其他类没有大问题,因为它们都使用构造函数注入.所以问题是 - 根本测试组合根是否有意义？它确实有一些额外的逻辑,但并不多,在大多数情况下,在应用程序启动期间会弹出任何故障.我有一些代码:

public void Initialize(/*Some configuration parameters here*/)
    {
        m_Container = new UnityContainer();

        /*Regestering dependencies*/

        m_Distributor = m_Container.Resolve<ISimpleFeedMessageDistributor>();
    }

    public void Start()
    {
        if (m_Distributor == null)
        {
            throw new ApplicationException("Initialize should be called before start");
        }

        m_Distributor.Start();
    }

    public void Close()
    {
        if (m_Distributor != null)
        {
            m_Distributor.Close();
        }
    }

Answer 1

根本测试组合物根本没有意义吗？

您想知道您的申请是否写得正确吗？你可能这样做,这就是你编写测试的原因.出于同样的原因,您应该测试您的组合根.

然而,这些测试专门针对系统布线的正确性.您不想测试单个类是否正常运行,因为某些单元测试已经涵盖了这一点.您也不想测试类是否以正确的顺序调用其他类,因为这是您要在常规集成测试中测试的内容(调用MVC控制器并查看调用是否在数据库中结束是此类集成测试的示例).

以下是您可能应该测试的一些内容:

• 可以解决所有顶级类.这可以防止您必须单击应用程序中的所有屏幕以查明是否所有内容都正确连接.
• 该组件仅依赖于同等或更长时间的服务.当组件依赖于配置了较短生命周期的另一个组件时,该组件将"提升"该依赖关系的生命周期,这通常会导致难以重现和修复的错误.检查此类问题很重要.这种类型的错误也称为生活方式不匹配或俘虏依赖.
• 应用程序和其他对应用程序正确性至关重要的拦截机制正确应用.装饰器可以例如添加交叉处理问题,例如事务处理,安全性和缓存,这些问题以正确的顺序执行是很重要的(例如,在查询缓存之前必须执行安全检查),但是很难使用正常的集成测试来测试它.

但是,为了能够执行此操作,您需要具有可验证的DI配置.

请注意,并非所有人都赞同此观点.但我的经验是,验证配置的正确性非常有价值.

因此,使用一些IoC容器测试这些东西可能具有挑战性,而其他IoC容器可以帮助您解决这个问题(但Unity很可能缺少大部分功能).

有些容器甚至可以调用某种验证方法来验证配置."验证"的含义因每个库而异.例如,Simple Injector(我是Simple Injector的主要开发者)有一个Verify方法,它将简单地迭代所有注册并调用GetInstance每个注册以确保可以创建每个实例.我总是建议用户Verify尽可能在他们的作文根中打电话.例如,这并不总是可行的,因为当配置变大时,对Verify的调用会导致应用程序启动太慢.但是,它仍然是一个很好的起点,可以消除很多痛苦.如果需要很长时间,您可以随时将呼叫转移到自动测试.

对于Simple Injector,这只是一个开始.Simple Injector包含诊断服务,用于检查容器是否存在常见的错误配置,例如前面提到的"生活方式不匹配"​​.

所以你应该绝对想要测试,但我不确定是否要将这些测试称为"单元测试",尽管我设法单独运行这些测试(无需访问数据库或Web服务).