如何组织集成测试？
在编写单元测试时，我通常每个生产类都有一个测试类，因此我的层次结构将如下所示：
src/main
-package1
-classA
-classB
-package2
-classC
src/test
-package1
-classATests
-classBTests
-package2
-classCTests
但是，在进行集成测试时，组织变得不那么严格。例如，我可能有一个测试类，它结合测试 classA 和 classB。你会把它放在哪里？一起测试 classA、classB 和 classC 的测试类怎么样？
此外，集成测试通常需要外部属性或配置文件。您将它们放置在哪里以及对它们使用任何命名约定吗？
When writing unit tests, I usually have one test class per production class, so my hierarchy will look something like that:
src/main
-package1
-classA
-classB
-package2
-classC
src/test
-package1
-classATests
-classBTests
-package2
-classCTests
However when doing integration tests the organization becomes less rigid. For example, I may have a test class that tests classA and classB in conjunction. Where would you put it? What about a test class that tests classA, classB and classC together?
Also, integration tests usually require external properties or configuration files. Where do you place them and do you use any naming convention for them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我们的集成测试往往以与规范相同的方式组织。它们往往按类别和/或功能收集。
Our integration tests tend to be organised the same way our specifications are. And they tend to be gathered by categories and/or feature.
我同意f4的回答。此类测试（级别高于UT）通常与特定类别没有相关性。您的测试应遵循项目要求和规范。
如果您确实需要开发一个适合您的测试需求的测试项目，我建议您使用以下方法：每个需求或用户故事包含一个单独的项目（取决于您管理需求的方法）。
例如：
src/itest -package1 - corresponds to story#1 -classA - test case1 -classB - test case2 -package2 - corresponds to story#1 -classC - test case2 -packageData - your common test data and utilities但是请记住，进行集成或系统级测试通常是一项复杂的任务，其范围很容易超出测试软件项目所能涵盖的范围。您应该准备好考虑第三方测试自动化工具，因为在集成或系统测试级别，它通常是比开发定制测试包更有效的方法。
I'd concur with f4's answer. Such kind of tests (level higher than UT) usually has no correlation with particular classes. Your tests should stick to project requirements and specifications.
In case you really need to develop a testing project tailored to your test requirements, I'd recommend the following approach: a separate project with packages per requirement or user story (depending on your approach to manage requirements).
For example:
src/itest -package1 - corresponds to story#1 -classA - test case1 -classB - test case2 -package2 - corresponds to story#1 -classC - test case2 -packageData - your common test data and utilitiesHowever keep in mind - doing an integration or system-level tests is usually complicated task and its scope could easily be broader than testing software project can cover. You should be ready to consider a third-party test automation tools, because at the level of integration or system test it's often a more efficient approach than developing a tailored testing package.
也许在 src/test 下创建一个集成测试目录？当然，对于集成测试，分离变得不太清楚，但是有一些东西将 A、B 和 C 组合在一起，不是吗？我会从这个开始，看看事情进展如何。立即想出一个完美的解决方案是很困难的，“好的”解决方案总比没有解决方案好。
Maybe create an integration tests directory under
src/test? Sure, for integration tests the separation becomes less clear, but there's something that groups A,B and C together, no? I'd start with this and see how things go. It's tough to come up with a perfect solution right away and an "OK" solution is better than no solution.看来您的集成测试是更高级别的单元测试，因为您仍然将它们绑定到一个或多个类。尝试从组中选择依赖于所有其他（传递）的类，并将测试与此类相关联。
如果您有真正的集成测试，那么与具体类的关联就没有什么价值。然后，测试按应用程序主题领域（域）和功能类型进行分类。例如，域是订单、发货、发票、权利等，功能类型是事务、Web、消息传递、批处理等。它们的排列将为您提供如何组织集成测试的良好初步切入点。
It seems that your integration tests are higher level unit tests since you still bind them to one or more classes. Try to pick class that depends on all others (transitively) from the group and associate test with such class.
If you have true integration tests then association with concrete classes is of little value. Then tests are classified by application subject areas (domains) and by types of functionality. For example, domains are orders, shipments, invoices, entitlements, etc. and functionality types are transactional, web, messaging, batch, etc. Their permutations would give you nice first cut of how to organize integration tests.
我发现，在进行 TDD 时，单元测试中的类和测试之间并不总是存在 1:1 的关系。如果你这样做，你将很难重构。事实上，经过一些重构后，我通常会得到大约 50% 的 1:1 耦合和 50% 的测试，您可以将它们链接到多个类或链接到单个类的测试集群。
如果您试图证明某些东西有效或无效，就会发生集成测试。当您因为需要交付某些东西而担心时，或者当您发现错误时，就会发生这种情况。试图从集成测试中获得全面覆盖是一个坏主意（温和地说）。
最重要的是测试需要讲述一个故事。用 BDD 的术语来说：如果你有这样的情况，那么当你这样做时，这应该会发生。测试应该是您希望人们如何使用单元、API、应用程序、服务等的示例。
您的测试的粒度和组织将遵循您的故事情节。它不应该预先设计成简单的规则。
I have found that when doing TDD it is not always the case that in unit tests there is a 1:1 relationship between classes and tests. If you do that you will have a hard time refactoring. In fact after some refactoring I usually end up with about 50% 1:1 couplings and 50% tests that you could link to several classes or clusters of tests that link to a single class.
Integration tests happen if you try to prove that something is or isn't working. This happens either when you're worried because you need to deliver something, or if you find a bug. Trying to get full coverage from integration tests is a bad idea (to put it mildly).
The most important thing is that a test needs to tell a story. In BDD'ish terms: given you have such, when doing this, that should happen. The tests should be examples of how you intend people to use the unit, API, application, service, ...
The granularity and organisation of your tests will follow from your storyline. It should not be designed with simplistic rules up front.