代码之家 › 专栏 › 技术社区 › Bobby

存在应用程序级和请求级IOC容器的测试系统

unity-container domain-driven-design dependency-injection unit-testing

1

Bobby · 技术社区 · 16 年前

我的团队正在开发一个系统,我们使用Unity作为我们的IOC容器;为了在每个HTTP请求上提供NHibernate ISessions(工作单元),我们使用Unity ChildContainer feature 为每个请求创建一个子容器,并将ISession粘贴在其中。

我们是在 trying others (including defining per-request lifetimes in the container, but there are issues there) 现在正试图决定单元测试策略。

现在,应用程序级容器本身在httpapplication中,请求容器在httpcontext.current中。显然,在测试期间两者都不存在。

当我们决定从域层使用服务位置来“懒惰地”解决容器中的依赖关系时,痛苦会增加。所以现在我们有更多的组件想要和容器对话。

我们也在使用MSTEST,它 presents some concurrency dilemmas 在测试过程中。

所以我们想知道,社会上那些聪明的人是怎么处理这种困境的?

如何设置一个在“真实”运行时依赖HTTP对象来保存容器的应用程序,但在测试期间,可以灵活地一致地构建和删除容器,并让serviceLocation位到达这些精确的容器。

希望问题清楚,谢谢!

谢谢你的回复。我同意使用服务位置不是最佳方法,但对于这种情况似乎确实是必要的。场景是我们需要我们的实体来解决依赖关系, 按需 ,仅在需要时-用于业务规则验证。强迫 全部的 我们的实体,在被NHibernate具体化后,接受构造函数注入,似乎不合适,至少出于性能原因。

我们正在考虑一种解决方案,在实际运行时将容器存储在httpapplication/httpcontext中,在测试期间存储在static/threadstatic字段中。 StructureMap has a similar approach baked-in . 对这种解决方案有什么想法吗?谢谢!

此外,这不一定是集成测试(尽管它也可能参与其中)。例如,我们希望对特定实体的业务规则行为进行单元测试——在此期间将展开此场景。

我对HTTP对象抽象绝对是开放的——我在MVC中使用过它们并且很喜欢它们;怎样才能让它们走出MVC呢?

1 回复 | 直到 16 年前

1

0

Community Mohan Dere 9 年前

DI容器 should not be necessary during unit testing . 相反,在应用程序启动时使用DI容器来解析应用程序的依赖关系图,以及 那就让开 .

但是,听起来您已经应用了 Service Locator anti-pattern 你现在感觉到了痛苦。不幸的是,没有一个简单的方法可以解决这个问题。

显然,在单元测试期间,您不能依赖真实的HTTP上下文,因为它在该环境中对您不可用,所以需要将它们隐藏在接口后面。如果您使用的是.NET 3.5 SP1,那么您可能可以使用System.Web.Abstractions中引入的抽象,否则,您可以自己提取一些。

一旦你介绍了这些接缝在您的系统中,您可以使用适当的依赖注入(最好是 构造器注入 )把它们注入你的消费类。

在任何情况下,以下 测试驱动开发 一开始就可以非常有效地防止这种紧耦合的引入。