代码之家 › 专栏 › 技术社区 › Tuukka Mustonen

集成测试的容器内测试与模拟对象

application-server integration-testing mocking testing java

Tuukka Mustonen · 技术社区 · 16 年前

容器内测试通常与模拟对象测试相反。然而,由于模拟对象只是模仿真实对象的行为,那么容器内测试不是在其“真实环境”中真正测试系统的唯一方法吗?

作为容器内测试和模拟对象的部分替代方案,Spring提供了 TestContext 框架可以很好地初始化Spring,而不需要启动实际的应用程序容器(在我的例子中是Web应用程序服务器)。但是,这种方法有点局限,因为它只初始化特定于Spring的功能,而不支持特定于应用服务器的功能。所以你不能测试一切。另外,因为它与默认值不完全相同 WebApplicationContext 这是在真正的网络执行中使用的,这种方法不是有点黑客吗?这不好吗?

对于容器内测试,至少有 Cactus (过时) Jeeunit (一个非常小的项目)和 JBoss Arquillian (仍然是阿尔法,但看起来很有前途)。我认为这些项目中没有一个应用得太广泛,那么容器内测试有什么不好的地方吗?在容器测试中经常提到的主要缺点是执行速度慢。但是,在持续集成环境和相对较小的项目中运行时,这不应该是问题。

总结:我们应该做集装箱内或集装箱外测试,为什么?在集成测试中使用模拟对象或其他初始化机制(如SpringTestContext)会感觉不好吗?

附言:我最近问过 categorization of integration test ,这可能是相关的。

2 回复 | 直到 16 年前

Gray droiddeveloper 16 年前

然而,由于模拟对象只是模仿真实对象的行为,所以不是容器中的测试真正在“真实环境”中测试系统的唯一方法?

我认为简短的回答是肯定的,但是…我认为你的“集成测试分类”问题非常相关。单元和集成测试是 二者都 重要的是,尽管服务于不同的功能。

单元测试与代码密切相关,应该启动和运行得非常快,应该经常由开发人员在代码上迭代运行,并且通常在很大程度上使用模拟。其思想是测试有问题的代码,而不是其依赖项或集成点。使单元测试都在容器中的问题是,它们运行的频率会降低,或者会浪费太多的开发人员时间。

我们在另一个依赖于代码项目的项目中的其他地方隔离了容器内/集成测试。它们被设计成尽可能地模拟生产配置。这些测试需要更长的时间来进行设置、运行更长的时间,并且更有用 cruisecontrol . 它们是手工运行的,特别是当我们接近一个版本或者开发已经稳定之后。通常我在午餐或会议时启动集成测试。当一个集成测试发现一个bug时,我们试图编写一个单元测试来用mock来演示这个bug——这通常很难,而且是不可能的。

我们通常有一些小的容器内测试和单元测试,只是为了确保Spring接线正常工作或测试一些基本功能,但是其余的集成测试是在另一个项目中完成的。

所有这些都表明,两者之间没有一个确切的区别。有时,我们移动处理大量数据的单元测试,花很长时间进行集成测试,有时集成测试运行得足够快,并且有足够的价值,可以与代码一起包含。

SteveD 16 年前

我想我们应该这么做 二者都 集装箱内和集装箱外测试。我在容器测试中发现的主要问题是,自动化所有东西的工作要多得多。通过Spring的集成测试支持,您可以获得一些更便宜的胜利,但是我们不应该愚弄自己,这涵盖了部署容器中测试的所有内容。

在模拟的主题上,我发现它们可以在与Spring的集成测试中发挥作用,但是我更倾向于使用带有屏蔽结果的假/存根服务进行集成和容器测试(我称之为系统测试)。

如果你不确定嘲弄和胡茬有什么区别,看看这个 Martin Fowler article .