junit：相互依赖的测试答案

【问题标题】：junit: Tests that rely on each otherjunit：相互依赖的测试
【发布时间】：2012-03-28 04:27:00
【问题描述】：

我在JUnit 测试结构方面遇到了架构难题。

我的测试类的流程测试从大文件加载字典。由于内存不足、找不到文件、文件结构错误等原因，该类可能会失败。

首先，按特定顺序运行测试很有意义：检查内存，然后检查文件是否存在，然后检查其结构。这将非常有帮助，因为如果我们没有足够的内存，适当的测试将会失败并给出有意义的输出，而不是神秘的OutOfMemoryException。而且，我不必费时费力地一遍遍地读取文件。

另一方面，测试应该是独立的、自包含的实体。

对如何设计测试套件有任何想法吗？

【问题讨论】：

我很好奇：当您收到OutOfMemoryError 时，究竟有什么神秘之处？
一个。它不会提示您所需的所需内存量。湾。如果使用交换文件，则可能需要很长时间才能引发异常。
你知道@Before注解吗？或者Assume.assumeTrue？
@RolandIllig 是的。如果不能保证测试的顺序，这些就没那么有用了。
我的想法是让checkHeapMemory 成为@Before 方法，因为它并不是真正的测试，而是先决条件。 checkFileExists 也一样。那么问题是您是想静默跳过测试（在实际测试方法中使用assumeTrue）还是想快速失败（使用@Before）。

标签： unit-testing architecture junit integration-testing

【解决方案1】：

您所描述的是集成测试，而不是单元测试。单元测试（理想情况下）不应依赖文件系统、可用内存量等。

您应该使用字典中可管理的数据量来设置单元测试（最好从测试夹具代码中的字符串（流）初始化，而不是从外部文件初始化）。这样您就可以为每个单元测试用例独立地重新初始化您的测试夹具，并测试您需要了解的有关字典结构的任何细节。

当然，您还应该创建单独的高级集成测试，以验证您的系统作为一个整体在现实生活环境下是否按预期工作。如果这些与真正的单元测试分开，您可以在任何代码更改后通过 JUnit 运行（便宜且快速）单元测试，并通过其他方式运行更昂贵的集成测试，这取决于它们需要多长时间，例如每晚一次。您还可以选择设置集成环境一次，然后以明确定义的顺序运行集成测试（通过 JUnit 以外的其他方式，例如 shell / 批处理脚本），或者为每个测试用例重新加载字典文件，作为在夜间构建期间，延长执行时间可能无关紧要。

【讨论】：

如何在 JUnit 中编写集成测试，以尊重测试流程？
@AdamMatan，您无法控制 JUnit 中测试的执行顺序。（在相同的实施版本和环境中，这是相当可预测的，但在新版本中或在不同环境中运行时，它可能会在没有警告的情况下发生变化。）我在上面的更新中提供了两种选择。
可以，只是不要使用@Test；您仍然可以创建具有确定顺序的测试套件。你不应该，几乎总是，但你可以。
@DaveNewton，好的，很好，我暗示“当以应有的方式使用 JUnit 时”:-) 实际上，您可以在单个测试中以固定顺序执行任意数量的测试方法。当然，这意味着所有这些测试都将被 JUnit 视为单个测试。
嗯，我的意思是一个测试套件；它们仍然是单独的测试。但我同意在这种情况下不是最好的处理方式；依赖顺序的测试是邪恶的。

【解决方案2】：

补充彼得所说的：

OOME unit 测试不会依赖于实际耗尽内存。相反，当加载的代码抛出 OOME 时，任何文件加载调用都应该做出适当的反应。这就是嘲笑/等等。用于--模拟正在测试的行为外部。（丢失文件/文件结构错误也是如此。）

IMO 加载对于 JVM 配置来说太大的文件对于在实际加载文件的代码中进行测试并不是一件有用的事情——只要文件加载的任何调用都能适当地处理 OOME——至少不在单元测试中。

如果在文件太大时加载的代码需要一些行为验证，我会考虑删除文件加载部分并强制 OOME，而不是实际加载一个巨大的文件，只是为了省时间。重申一下他的观点，实际的物理行为可以转移到集成测试中，例如，在您自己的 TDD 心跳之外的 CI 服务器上运行。

【讨论】：