容器内测试通常反对使用模拟对象进行测试。但是，由于模拟对象只是模仿真实对象的行为，因此容器内测试不是在真实环境中真正测试系统的唯一方法吗？
作为容器内测试和模拟对象的部分替代，Spring提供了TestContext框架，可以很好地初始化Spring，而无需启动实际的应用程序容器（在我的情况下是Web应用程序服务器）。但是，这是一种有限的方法，因为它只初始化特定于Spring的功能，而不支持特定于应用程序服务器的功能。所以你无法测试一切。此外，由于它与真实网络执行中使用的默认WebApplicationContext不是100％相同，这种方法是不是有点hackyish？这不好吗？
对于容器内测试，至少Cactus（过时），Jeeunit（一个非常小的项目）和JBoss Arquillian（仍然是alpha，但看起来很有希望）。我没有看到任何这些项目被广泛使用，所以容器内测试有什么不好吗？容器内测试经常提到的主要缺点是执行速度慢。但是，当在持续集成环境和相对较小的项目中运行时，这应该不是问题。
总结一下：我们应该进行容器内或容器外测试吗？为什么？使用模拟对象或其他初始化机制（如在Spring TestContext中）进行集成测试会不会感觉不好？
一个子注释：我最近询问了categorization of integration test，这可能是相关的。
答案 0 :(得分：3)
但是，由于模拟对象只是模仿真实对象的行为，因此不是容器内的 测试在真实环境中真正测试系统的唯一方法吗？
我认为简短的回答是肯定的，但是......我认为你的“整合测试分类”问题非常重要。单元和集成测试都很重要，尽管它们具有不同的功能。
单元测试与代码紧密相关，如果启动和运行速度非常快，应该经常由开发人员迭代代码运行，并且通常在很大程度上使用模拟。我们的想法是测试有问题的代码，而不是它的依赖关系或集成点。将单元测试全部放在容器中的问题是它们运行频率较低或者会浪费太多的开发时间。
我们在另一个项目的其他地方隔离了我们的容器内/集成测试，并依赖于代码项目。它们旨在尽可能地模拟生产配置。这些测试需要更长时间才能完成设置，运行时间更长，并且更适合cruisecontrol之类的运行。它们是手工运行的，特别是当我们关闭一个版本或开发稳定后。我经常在午餐或开会时开始进行集成测试。当集成测试发现错误时，我们会尝试编写一个单元测试来演示模拟的错误 - 这通常很难并且是不可能的。
我们通常在单元测试中进行一些小型容器内测试，以确保弹簧接线工作或测试一些基本功能，但其余的集成测试在另一个项目中完成。
所有这些都说，两者之间没有明显的区别。有时我们移动单元测试只处理大量数据并花费很长时间进行集成测试，有时集成测试运行得足够快，并且足够有价值，可以与代码一起包含。
答案 1 :(得分：2)
我会说我们应该 in-container和out-container测试。我在集装箱测试中发现的主要问题是自动化所有事情要做的工作要多得多。你可以通过Spring的集成测试支持获得一些更便宜的胜利，但是我们不应该欺骗自己，这涵盖了部署容器中测试的所有内容。
关于模拟的主题，我发现他们可以参与Spring的集成测试，但我更有可能使用带有预制结果的假/存根服务进行集成和容器内测试（我会呼叫系统测试）。
如果您不确定模拟和存根之间的区别，请查看此Martin Fowler article。