单元测试IoC注册？

Question

你应该单元测试将组件注册到你的IoC容器的代码吗？

如果是这样，怎么样？

Answer 1

由于你的组件可能有它们自己的依赖关系或执行一些初始化，所以我会用UT来覆盖这个场景。

喜欢的东西

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

Answer 2

在春天，你可以简单地加载应用程序上下文没有任何断言单元测试。它实际上是一个与自动构建相结合的相当有用的测试，因为在加载完整上下文时，spring会抱怨很多问题。

Answer 3

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

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

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

一般来说，我发现写作测试作为断言关于整个系统是非常有用和有价值的。

E.g.我还声称所有的控制器操作都是虚拟的，这是必需的，因为我使用Castle的自动事务管理来将控制器操作与事务进行环绕。

Answer 4

@aku，@krosenvold和@mookid为测试依赖关系的配置是否正确提供了一个引人注目的参数。
我不认为这是单元虽然测试。
你在测试什么？你不是试图单元测试容器本身（可能这不是你编写或维护的代码）。
您试图测试的是，可以创建特定类型的所有依赖关系，并且可以解析该类型。这听起来像是一个非常有用的系统测试或集成测试，可以在您的持续集成环境中使用。
因此，一旦你有通过单元测试的二进制文件，你可以创建容器并在一台镜像你的生产环境的机器上运行容器的设置，并测试容器应该能够解析的每种类型被创建并且它们的所有依赖可以被实例化。
这将是一个很好的运行在一个新的虚拟机，你已经应用了你的最新安装程序。

Answer 5

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

Answer 6

它让我感觉不对，让IoC容器在我的测试项目中运行。我还注意到，大部分由依赖没有解决的错误都是由顺序依赖解决的，这很难测试，而且不是我想做单元测试的东西。

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

Answer 7

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

同样的方法应该与任何IoC容器或其他系统，其配置是如此复杂，它可能会破坏工作 - 除非它是需要通过测试不写任何配置。

Answer 8

回答这个问题，专门为Castle Windsor：

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