容器内测试与模拟对象进行集成测试 [英] In-container testing vs. mock objects for integration testing
问题描述
容器内测试通常与使用模拟对象进行测试相反.但是，由于模拟对象只是模仿真实对象的行为，因此容器内测试不是唯一在真实环境中真正测试系统的唯一方法吗?
In-container testing is often opposed to testing with mock objects. 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?
作为容器内测试和模拟对象的部分替代，Spring提供了TestContext框架，可以很好地初始化Spring，而无需启动实际的应用程序容器(在我的情况下为Web应用程序服务器).但是，这是一种有限的方法，因为它仅初始化特定于Spring的功能，而不支持特定于应用程序服务器的功能.因此，您无法测试所有内容.另外，由于它与实际Web执行中使用的默认WebApplicationContext不是100％相同，因此这种方法是否有点怪异?不好吗?
As an partial alternative to in-container testing and mock objects, Spring provides the TestContext framework that initializes Spring nicely without needing to start up the actual application container (web application server, in my case). However, this is somewhat limited approach as it only initializes Spring-specific features while the application server -specific features are not supported. So you cannot test everything. Also, as it is not 100% the same as the default WebApplicationContext that is used in real web execution, isn't this approach a bit hackyish? Is it bad?
对于容器内测试，至少有仙人掌(已过时)， Jeeunit (一个非常小的项目)和
For in-container testing, there are at least Cactus (outdated), Jeeunit (a very little project) and JBoss Arquillian (still alpha, but looks promising). I don't see any of these projects too widely used, so is there something bad with in-container testing? The main drawback often mentioned with in-container testing is slow execution speed. However, when run in a continuous integration environment and in a relatively small project, this shouldn't be a problem.
总结:我们应该进行容器内还是容器外测试，为什么?使用集成对象的模拟对象或替代初始化机制(如Spring TestContext)会感到难受吗?
To summarize: should we do either in-container or out-container testing and why? Would you feel bad using mock objects or an alternative initialization mechanism (as in Spring TestContext) for your integration tests?
A subnote: I recently asked about categorization of integration test, which might be relevant.
推荐答案
但是，由于模拟对象只是模仿真实对象的行为，因此不是容器内 测试在真实环境中真正测试系统的唯一方法?
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?
我认为简短的答案是肯定的，但是...我认为您的集成测试分类"问题非常相关.单元测试和集成测试都很重要，尽管它们的功能不同.
I think the short answer is yes, but... I think your "categorization of integration test" question is very relevant. Unit and integration tests are both important although the serve different functions.
单元测试与代码紧密相关，应该非常快速地启动和运行，应该经常由开发人员对代码进行迭代来运行，并且通常会高度使用模拟.想法是测试有问题的代码，而不是其依赖项或集成点.使单元测试全部包含在容器中的问题是，它们的运行频率将降低，否则将浪费过多的开发人员时间.
Unit tests are closely associated with the code, should startup and run very fast, should be run often by developers iterating on the code, and usually use mocks to a high degree. The idea is to test the code in question, not its dependencies or integration points. The problem with making the unit tests all be in-container is that they will be run less often or they will waste too much developer time.
我们已将依赖于代码项目的其他容器/集成测试隔离到另一个项目的其他位置.它们旨在紧密模拟生产配置-尽可能地.这些测试的设置时间更长，运行时间更长，并且对于诸如 cruisecontrol 之类的工具运行更有用.它们是手工运行的，尤其是在我们即将发布或稳定开发之后.当我要去吃午餐或开会时，我通常会启动集成测试.当集成测试发现错误时，我们尝试编写一个单元测试，同时通过模拟来演示该错误-这通常很困难，而且不可能.
We have isolated our in-container/integration tests elsewhere in another project with dependencies on the code projects. They are designed to closely mimic production configurations -- as much as possible. These tests take longer to setup, run longer, and are more useful to run by something like cruisecontrol. They are run by hand especially when we are closing in on a release or after development has stabilized. Often I fire up the integration tests when I'm going to lunch or a meeting. When an integration test discovers a bug, we try to write a unit test that also demonstrates the bug with the mocks -- this is often hard and can be impossible.
我们通常会进行一些小型的容器内测试和单元测试，以确保弹簧接线有效或测试一些基本功能，而其余的集成测试则在另一个项目中完成.
We usually have a couple small in-container tests with the unit tests just to make sure that the spring wiring works or to test some basic functionality but the rest of the integration testing is done in another project.
所有这些，两者之间没有明显的区别.有时我们移动仅处理大量数据的单元测试，并花很长时间进行集成测试，有时集成测试运行得足够快且有价值，足以与代码一起包含.
All this said, there is not a firm difference between the two. Sometimes we move unit tests that just deal with a lot of data and take a long time out to integration tests and sometimes integration tests run fast enough and are valuable enough to be included along with the code.
这篇关于容器内测试与模拟对象进行集成测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
