由于surefire插件的fork模式，单元测试失败 [英] Unit test failing due to surefire plugin's forkmode

问题描述

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

There is a test in my code which creates a directory and then creates a file inside it.

但是，该测试失败，因为写入文件的测试部分无法找到创建的目录.唯一解决此问题的方法是将surefire插件设置为永不分叉，如下所示:

However, this test fails as the portion of the test that writes the file is not able to find the directory that is created. The only thing that fixes it is to set the surefire plugin to never fork like so:

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

我会将此修复解释为意味着在一个JVM进程中创建目录，而在另一个JVM进程/线程中创建文件?

I would interpret this fix to mean that the directory is created in one JVM process and the file is created in another JVM process/thread ?

此测试失败被隔离到仅在最近才开始失败的单台计算机上.

This test failure is isolated to a single machine on which it has started failing only recently.

我尝试过的几件事是:

1. 系统上有许多JDK版本浮动，因此除在多个其他系统(1.6.0_19)上运行的版本外，所有版本都已被删除.
2. 尝试从Administrator cmd提示符在该项目上运行"mvn测试".
3. 检查父目录的权限是否正确.
4. 尝试从头开始检查整个项目并执行相同的操作.
5. 检查是否已将发生此情况的目录排除在AntiVirus的On-Access-Scanner中.

以上似乎都不起作用.唯一有所不同的是<forkMode>配置.我无法弄清楚为什么在它周围或正在测试的功能中完全没有代码更改时该测试突然停止工作.

None of the above seem to have any effect. The only thing that makes a difference is the <forkMode> config. I can't figure out why that test suddenly stopped working when there have been absolutely no code changes around it or in the functionality that it's testing.

所使用的maven-surefire-plugin的版本为

The version of maven-surefire-plugin being used is 2.12.4. Updating to the latest (2.14.1) does not fix the test if the `never' config is missing.

<forkMode>已已弃用，但仅从2.14版开始.

<forkMode> is deprecated but only since version 2.14.

我对潜在问题可能真的很感兴趣.我希望最终的结论不会像HDD或硬件问题那样简单.

I am really intrigued by what the underlying issue might be. I am hoping that the final conclusion is not something as simple as this being a HDD or hardware issue.

推荐答案

tl; dr:已修复！

tl;dr : Fixed !

为用户制造了另一台全新的机器.它工作了一个小时左右，然后又发现完全相同的问题.

Another brand new machine was built for the user. It worked fine for an hour or so and then after that, lo and behold, the exact same issue.

普遍的共识是，它必须是流氓Windows更新.因此，我们尝试了几件事，例如将计算机还原到以前的状态.手动卸载Windows更新，等等.

The general consensus was that it MUST be a rogue windows update. So we tried a couple of things, like restoring the machine to a previous state. Uninstalling windows updates manually etc. Nothing worked.

然后，机器的拥有者顿悟了.显然，他已经习惯了 此 注册表黑客，这就是此超级神秘错误的原因.我们撤消了该操作，然后将mvn clean install正常运行即可！

Then the owner of the machine had an epiphany. Apparently, he had gotten used to this registry hack, which was the reason for this uber mysterious error. We undid that, and voilà the mvn clean install worked fine !

尽管我仍然很奇怪为什么它会影响Java进程，所以这里有一个后续问题:

I am still very curious though about why it would affect a java process, so here is a follow up question around it : Why does this autorun-cmd registry hack affect a java/maven process? (Complete with a gihub repo to isolate the offending code.)

感谢所有有用的评论.

这篇关于由于surefire插件的fork模式，单元测试失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！