如何组织集成测试？答案

【问题标题】：How to organize integration tests?如何组织集成测试？
【发布时间】：2010-02-11 23:09:21
【问题描述】：

在编写单元测试时，我通常每个生产类都有一个测试类，所以我的层次结构看起来像这样：

src/main
  -package1
    -classA
    -classB
  -package2
    -classC
src/test
  -package1
    -classATests
    -classBTests
  -package2
    -classCTests

但是，在进行集成测试时，组织变得不那么僵化了。例如，我可能有一个测试类，它同时测试 classA 和 classB。你会把它放在哪里？一个同时测试 classA、classB 和 classC 的测试类呢？

此外，集成测试通常需要外部属性或配置文件。你把它们放在哪里，你有没有为它们使用任何命名约定？

【问题讨论】：

标签： unit-testing architecture integration-testing

【解决方案1】：

我们的集成测试的组织方式往往与我们的规范相同。它们往往是按类别和/或特征来收集的。

【讨论】：

这个答案根本没有帮助，也不值得任何支持：-|

【解决方案2】：

我同意 f4 的回答。此类测试（高于 UT 的级别）通常与特定类别没有相关性。您的测试应遵循项目要求和规范。

如果您确实需要根据您的测试需求开发一个测试项目，我建议您采用以下方法：一个单独的项目，每个需求或用户故事都有包（取决于您管理需求的方法）。例如：

源/测试 -package1 - 对应故事#1 -classA - 测试用例1 -classB - 测试用例2 -package2 - 对应故事#1 -classC - 测试用例2 -packageData - 您常用的测试数据和实用程序

但请记住 - 进行集成或系统级测试通常是一项复杂的任务，其范围很容易超出测试软件项目所能涵盖的范围。您应该准备好考虑使用第三方测试自动化工具，因为在集成或系统测试级别，它通常比开发定制的测试包更有效。

【讨论】：

【解决方案3】：

也许在src/test 下创建一个集成测试目录？当然，对于集成测试，分离变得不太清楚，但是有些东西将 A、B 和 C 组合在一起，不是吗？我会从这个开始，看看事情进展如何。马上想出一个完美的解决方案是很困难的，一个“OK”的解决方案总比没有解决方案好。

【讨论】：

【解决方案4】：

您的集成测试似乎是更高级别的单元测试，因为您仍然将它们绑定到一个或多个类。尝试从组中选择依赖于所有其他人（及物）的课程，并将测试与此类课程相关联。

如果您有真正的集成测试，那么与具体类的关联就没有什么价值了。然后按应用主题领域（领域）和功能类型对测试进行分类。例如，域是订单、发货、发票、权利等，功能类型是事务性、Web、消息传递、批处理等。它们的排列将使您很好地了解如何组织集成测试。

【讨论】：

【解决方案5】：

我发现在进行 TDD 时，在单元测试中类和测试之间并不总是存在 1:1 的关系。如果你这样做，你将很难重构。事实上，经过一些重构后，我通常会得到大约 50% 的 1:1 耦合和 50% 的测试，您可以链接到多个类或链接到单个类的测试集群。

如果您试图证明某事有效或无效，就会进行集成测试。当您因为需要交付某些东西而担心或发现错误时，就会发生这种情况。试图从集成测试中获得全面覆盖是一个坏主意（委婉地说）。

最重要的是，测试需要讲述一个故事。用 BDD 的术语来说：如果你有这样的情况，那么在这样做时，应该会发生这种情况。测试应该是您打算让人们如何使用单元、API、应用程序、服务的示例......

您的测试的粒度和组织将遵循您的故事情节。它不应该预先设计简单的规则。

【讨论】：