java - 容器内测试与用于集成测试的模拟对象

Question

容器内测试通常与使用模拟对象进行测试相反。然而，由于模拟对象只是模仿真实对象的行为，容器内测试难道不是在真实环境中真正测试系统的唯一方法吗？

作为容器内测试和模拟对象的部分替代方案，Spring 提供了 TestContext 框架，它可以很好地初始化 Spring，而无需启动实际的应用程序容器(在我的例子中是 Web 应用程序服务器) .然而，这是一种有限的方法，因为它只初始化特定于 Spring 的功能，而不支持特定于应用程序服务器的功能。所以你不能测试所有的东西。此外，由于它与实际 Web 执行中使用的默认 WebApplicationContext 不是 100% 相同，所以这种方法是不是有点 hackyish？不好吗？

对于容器内测试，至少有Cactus (过时)，Jeeunit (一个非常小的项目)和 JBoss Arquillian (仍然是 alpha，但看起来很有希望)。我没有看到这些项目中的任何一个被广泛使用，那么容器内测试有什么不好的地方吗？容器内测试经常提到的主要缺点是执行速度慢。但是，当在持续集成环境和相对较小的项目中运行时，这应该不是问题。

总结一下:我们应该进行容器内测试还是容器外测试，为什么？使用模拟对象或替代初始化机制(如在 Spring TestContext 中)进行集成测试，您会感觉不好吗？

附注:我最近询问了关于 categorization of integration test 的问题，这可能是相关的。

Answer 1

However, as mock objects simply mimic the behavior of the real objects, isn't the in-container testing the only way to really test the system in its' real environment?

我认为简短的回答是肯定的，但是...我认为您的“集成测试分类”问题非常相关。单元测试和集成测试都很重要，尽管它们具有不同的功能。

单元测试与代码密切相关，应该启动和运行得非常快，应该由开发人员在代码上迭代时经常运行，并且通常会高度使用模拟。这个想法是测试有问题的代码，而不是它的依赖项或集成点。将单元测试全部置于容器内的问题在于，它们的运行频率会降低，或者会浪费开发人员太多时间。

我们已将我们的容器内/集成测试隔离在另一个项目的其他地方，并依赖于代码项目。它们旨在尽可能地模仿生产配置。这些测试需要更长的时间来设置，运行更长时间，并且通过类似 cruisecontrol 的方式运行更有用。 .它们是手动运行的，尤其是当我们即将发布或开发稳定后。我经常在去吃午饭或开会时启动集成测试。当集成测试发现错误时，我们尝试编写一个单元测试，该测试还通过模拟来演示错误——这通常很难，而且可能是不可能的。

我们通常会在单元测试中进行一些小型容器内测试，以确保 Spring 布线正常工作或测试一些基本功能，但其余的集成测试是在另一个项目中完成的。

综上所述，两者之间并没有明显的区别。有时我们将只处理大量数据的单元测试移到集成测试中花费很长时间，有时集成测试运行得足够快并且足够有值(value)，可以与代码一起包含在内。