如何组织集成测试？

Question

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

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

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

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

Answer 1

我们的集成测试的组织方式与我们的规范相同。并且它们倾向于按类别和/或特征收集。

Answer 2

也许在src/test下创建一个集成测试目录？当然，对于集成测试，分离变得不那么清晰了，但有一些东西将A，B和C组合在一起，不是吗？我从这开始，看看情况如何。很难立即找到一个完美的解决方案，“OK”解决方案比没有解决方案更好。

Answer 3

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

如果您有真正的集成测试，那么与具体类的关联几乎没有价值。然后根据应用主题领域（域）和功能类型对测试进行分类。例如，域名是订单，货件，发票，权利等，功能类型是交易，网络，消息传递，批处理等。它们的排列将为您提供如何组织集成测试的第一步。

Answer 4

我同意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

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

Answer 5

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

如果您尝试证明某些内容有效或无效，则会发生集成测试。当你担心因为你需要提供某些东西，或者你发现了一个错误时，就会发生这种情况。试图从集成测试中获得全面的报道是一个坏主意（说得客气一点）。

最重要的是测试需要讲述一个故事。在BDD'ish术语中：如果你有这样的话，那么这样做应该会发生。测试应该是您打算如何使用单位，API，应用程序，服务......的示例。

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