java - 由于 surefire 插件 forkmode 导致单元测试失败

Question

我的代码中有一个测试，它创建一个目录，然后在其中创建一个文件。

但是，此测试失败，因为写入文件的测试部分无法找到创建的目录。唯一修复它的方法是将 surefire 插件设置为永不 fork :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <forkMode>never</forkMode>
    </configuration>
</plugin>

我会将此修复解释为目录是在一个 JVM 进程中创建的，而文件是在另一个 JVM 进程/线程中创建的？

此测试失败被隔离到最近才开始失败的一台机器上。

我尝试过的一些事情是:

1. 系统上有许多 JDK 版本，所以除了在许多其他系统 (1.6.0_19) 上运行的版本之外，其他所有版本都被删除了。
2. 尝试从管理员 cmd 提示符在该项目上运行“mvn 测试”。
3. 检查父目录权限是否正常。
4. 尝试从头开始检查整个项目并执行相同的操作。
5. 检查发生这种情况的目录是否已从 AntiVirus 的按访问扫描程序中排除。

以上似乎都没有任何效果。唯一有所不同的是 <forkMode>配置。我不明白为什么当它周围或它正在测试的功能中绝对没有代码更改时，该测试突然停止工作。

正在使用的 maven-surefire-plugin 版本是 2.12.4 .如果缺少“从不”配置，则更新到最新版本 (2.14.1) 不会修复测试。

<forkMode>是deprecated但仅从 2.14 版开始。

我真的很想知道潜在的问题是什么。我希望最终的结论不是硬盘或硬件问题这么简单。

Answer 1

tl;dr:已修复!

又为用户打造了一台全新的机器。它在一个小时左右的时间内运行良好，然后，你瞧，完全相同的问题。

普遍的共识是它一定是恶意的 Windows 更新。所以我们尝试了一些事情，比如将机器恢复到以前的状态。手动卸载 Windows 更新等。没有任何效果。

然后机器的主人顿悟了。显然，他已经习惯了 this registry hack，这是这个 super 神秘错误的原因。我们取消了它，瞧，mvn clean install 工作正常!

我仍然很好奇为什么它会影响 java 进程，所以这里有一个关于它的后续问题:Why does this autorun-cmd registry hack affect a java/maven process?(完成一个 gihub 存储库以隔离有问题的代码。)

感谢所有有用的评论。