Question

您是否应该将注册组件的代码单元测试到您的IoC容器中？

若然，怎么样？

Answer 1

在Spring中，您可以进行单元测试，只需加载应用程序上下文而不断言任何内容。它实际上是一个与自动构建相关的非常有用的测试，因为Spring在加载完整的上下文时会抱怨很多问题。

Answer 2

在我的测试项目中运行IoC容器对我来说有点不对。我还注意到，依赖关系未解决的大多数错误是由顺序依赖性解决引起的，这很难正确测试，而不是我想要做的单元测试。

通常我在类的初始化例程中使用Debug.Assert语句。这为IoC相关错误提供了一个早期预警系统，并且还有助于在我的代码中更好地指定依赖关系。

Answer 3

@aku，@ krosenvold和@mookid为测试依赖关系的配置是否正确提出了令人信服的论据。
我不认为这是 unit 测试你在测试什么？您不是要对容器本身进行单元测试（可能不是您编写或维护的代码）您要测试的是，可以创建特定类型的所有依赖项，并且可以解析该类型。这听起来像是一个非常有用的系统测试或集成测试，可以在您的持续集成环境中使用因此，一旦您拥有通过单元测试的二进制文件，您就可以创建容器并在镜像生产环境的机器上运行容器设置，并测试实际上可以创建容器应该能够解析的每种类型并且可以实例化所有依赖项在你已经应用最新安装程序的新VM中运行它会很不错。

Answer 4

我对Guice IoC容器所做的是首先使用没有Guice的TDD（这些是单元测试）生成某些功能的类。然后我用Guice为该功能创建集成测试。此时IoC配置（Guice模块）不完整，因此集成测试将失败。使用TDD，我逐步添加IoC配置，直到集成测试通过。除非需要通过测试，否则我不会添加任何@Inject批注，配置行或范围声明。因此，我将进行集成（或验收）测试，确保IoC配置正确且完整。

这种方法适用于任何IoC容器或其他系统，其配置非常复杂，可能会中断 - 除非需要通过测试，否则不要编写任何配置。

Answer 5

由于您的组件可能有自己的依赖项或执行某些初始化，因此我将使用UT来覆盖此场景。

像

这样的东西

iocContainer.Register(typeof(MyService1));
service = iocContainer.Get(typeof(MyService));
Debug.AssertNotNull(service);

Answer 6

我在ASP.NET MVC项目中使用Windsor，我编写了一个简单的测试来验证是否可以实例化所有控制器（即可以解析它们的依赖关系）。

我对网站的每个配置进行了测试（例如“开发”，“测试”，“someProductionSite”等），其中我使用该特定配置创建我的Windsor容器并循环遍历所有非抽象实现IController，检查我是否可以解析每个实例。

由于控制器工厂是进入应用程序的唯一入口点，将导致container.Resolve（...），我100％确定所有配置都有效。

通常，我发现编写充当整个系统断言的测试非常有用且有价值。

E.g。我也断言所有控制器操作都是虚拟的，这是一个要求，因为我使用Castle的自动事务管理来围绕控制器操作与事务。

Answer 7

它可能很有用，因为一些依赖注入框架（如Unity）具有选择调用哪个构造函数的奇怪规则。我肯定会建议单元测试，以确保您的类型的注册和创建成功。

Answer 8

专门针对Castle Windsor回答这个问题：

Castle Windsor: How to test that all registered components are resolvable?

单元测试IoC注册？

8 个答案: