单元测试应仅涵盖“功能性”软件

我们正在一个新的软件开发项目中使用StructureMap。团队成员之一已实现了一个单元测试，该单元测试基本上测试了StructureMap容器配置。它通过执行以下操作来做到这一点；

• 计算为应用程序名称空间中的类配置的程序集的实例数。
• 在类级别定义期望的实例
• 断言预期实例与找到的实例总数匹配。
• 断言预期实例与测试中定义的实例匹配

一个例子是；

var repositories = container.GetAllInstances<IEnvironmentRepository>();
Assert.AreEqual(1, repositories .Count());
foundInstances = foundInstances + repositories .Count();

我们还为下一节课提供“单元测试”；

public MyClass(IEnvironmentRepository environmentRepository)
        {

        }

在这些测试中，我们模拟了IEnvironmentRepository，因此不会像在实时系统中那样从容器中注入它。

一位同事忽略了对结构图配置的单元测试，并带有“单元测试仅测试它自己的配置”的注释。这显然是测试的目的，我认为这是完全正确的。我要求忽略测试的人删除结构映射配置IEnvironmentRepository（仍然忽略测试）并运行完整的单元测试套件，它们都通过了。然后，我们运行了该应用程序，由于容器配置现在无效，因此该应用程序崩溃了。我认为，这证明了测试的价值，我的同事仍然不同意。他只是简单地说我们不应该测试配置，但是我认为这完全可以进行单元测试。

有很多问题；

• 这是有效的单元测试吗？-我们正在测试容器的配置，而不是结构图起作用（但我可以看到重叠的部分）
• 如果不是，您如何在不测试的情况下验证配置。您如何阻止某人意外删除所需的代码行并将其检入？
• MyClass单元测试是否应该IEnvironmentRepository从容器中解析出实例并传递给它？

这是一个完全有效的自动化测试。我称它们为“架构测试”，是因为它们可以验证代码库的骨骼组件的健全性。

IoC容器是否能够解析和组合应用程序中的所有对象树？自动Mapper可以在所有已注册对象之间进行映射而不会失败吗？洋葱架构中的中央层是否不引用任何外部内容？

通过指出确切的罪魁祸首，这些测试可以在配置错误发生时为您节省大量时间。好的框架会为您提供关于错误原因的非常精确的错误消息，并且您可以在运行测试后（理想情况下是连续地）立即获得它们，而不必走运，如果幸运的话，也不必深入了解运行时堆栈跟踪。

无论它们是否是单元测试……也许不是，但是它们仍然在内存中运行大部分并且运行非常快。再说一次，我不知道，这不像有一个普遍接受的单元测试定义。

像这样的测试的问题，它测试程序的内部而不是要求。即使程序按要求工作，测试是否也会失败？

在您的情况下，每当更改容器设置时，也许您有一个需要注入的新依赖项，就会破坏测试。

此外，如果您添加了额外的依赖项要求，但忘记将其添加到容器中并更改了容器测试。一切都会过去，但是您的程序将崩溃。

更好的自动化测试是启动程序，看看它是否崩溃。

您应该在集成或UI测试中捕获这些类型的错误，即使它们属于单元测试范围。

话虽这么说，容器设置的复杂性越来越高，这是一个麻烦。也许一些“不好的”测试是值得的。

单元测试测试代码。除此之外，还有“其他”自动化测试-随便怎么说。您似乎在这里测试配置。如果配置可以根据环境而更改，则它不属于单元测试。考虑添加一个测试属性以指示该测试与其他测试的类型不同。

依赖注入容器的职责是在一个工作应用程序中粘贴不同的模块。

如果您为应用程序编写自动化测试-您应该只有很少的“集成（或验收）测试”可以“端到端”执行测试，这些测试将测试应用程序的整个管道，从而将特定测试用例中涉及的所有模块粘合在一起正确的。

因此，如果未正确配置依赖项注入容器，则这些集成测试将失败。这会使容器本身的单元测试无用，因为集成测试应该显示容器配置中可能的错误。

您不需要在集成测试中涵盖所有可能的测试用例，每个功能只需一个测试用例即可涵盖从UI到数据库的完整方法。

如果集成测试用例不包括某些特定依赖的实例化，则只需添加这样的实例。

使用集成测试，您可以自由更改容器，而无需为它们的配置重写单元测试。

IMO，答案是：

1. 这是有效的单元测试吗？-我们正在测试容器的配置，而不是结构图起作用（但我可以看到重叠的部分）

   • 它是针对structuremap的有效单元测试，而不是针对您的项目的有效单元测试，因为单一测试会测试一些特定的代码，并在必要时模拟所有依赖项以测试实现的逻辑。配置逻辑是在structuremap内实现的，因此该库必须经过良好的测试，并且必须包含您所提到的单元测试，以及更多内容：它应该包含数百个这样的测试，在运行时动态模拟多个配置并进行测试以查看是否容器行为正常。

2. 如果不是，您如何在不测试的情况下验证配置。您如何阻止某人意外删除所需的代码行并将其检入？

   • 您可以在所需的环境中手动测试配置，也可以为此创建一个自动化（自动化测试），以测试所需的特定配置（无需在运行时模拟内容）。

3. MyClass单元测试是否应该从容器中解析IEnvironmentRepository的实例并将其传递给它？

   • 不，这是一个完美的单元测试，因为您可以模拟依赖关系并以隔离的方式测试MyClass逻辑。

UnitTest验证分离中某个单元的期望行为。

这是指任何类型的配置是不是在范围单元测试。

尽管如此，您应该对配置进行自动化测试，但这不是UnitTests ...