由于用于kmode的surefire插件，单元测试失败

Question

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

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

<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. 尝试从Administrator cmd提示符对该项目运行'mvn test'。
3. 检查父目录的权限是否合适。
4. 尝试从头开始检查整个项目并做同样的事情。
5. 检查发生这种情况的目录是否已从AntiVirus的On-Access-Scanner中排除。

以上都不会产生任何影响。唯一有所作为的是<forkMode>配置。我无法弄清楚为什么该测试突然停止工作时，它周围没有任何代码更改或它正在测试的功能。

正在使用的maven-surefire-plugin版本为2.12.4。如果缺少“never”配置，则更新到最新版本（2.14.1）不会修复测试。

<forkMode>为deprecated，但仅限于版本2.14。

我真的很感兴趣的是潜在的问题。我希望最后的结论并不像硬盘驱动器或硬件问题这么简单。

Answer 1

tl;博士：已修复！

为用户构建了另一台全新的机器。它运作良好一个小时左右然后在那之后，看，完全相同的问题。

普遍的共识是它必须是一个流氓Windows更新。所以我们尝试了一些方法，比如将机器恢复到以前的状态。手动卸载Windows更新等。没有任何效果。

然后机器的主人顿悟了。显然，他已经习惯了 this 注册表黑客，这就是这个超级神秘错误的原因。我们解决了这个问题，并且mvn clean install工作正常！

我仍然很好奇它为什么会影响java进程，所以这里有一个跟进问题：Why does this autorun-cmd registry hack affect a java/maven process? （完成gihub repo以隔离有问题的代码。）

感谢所有有用的评论。