Unit test failing due to surefire plugin's forkmode

Question

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

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>

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.

A couple of things that I have tried are :

There were numerous JDK versions floating around on the system, so got rid of all except the one that was working on a number of other systems ( 1.6.0_19 ).
Tried running the 'mvn test' on that project from an Administrator cmd prompt.
Checked that the permissions of the parent directory are fine.
Tried checking out the whole project from scratch and doing the same.
Checked that the directory where this was happening was excluded from AntiVirus' On-Access-Scanner.

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.

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> is deprecated but only since version 2.14.

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.

Is the directory created in a test `setUp()` method or in another test case? Do you create distinct directories for each test or is it shared among tests? Remember that test cases may be reordered or run in parallel and - depending on the test logic - that could lead to concurrent modifications to the directory. — Pyranja, Apr 24 '13 at 08:22
Strange! It's not quite clear to me if it's two separate tests that create the dir and write the file, or if both things happens in the same test method? Test execution order can be randomly reordered by the test runner. — Anders R. Bystrup, Apr 24 '13 at 08:24
@Pyranja Spot on! The directory is being created in a setUp() method and there are two tests that then try to create files in that directory. But I had also tried after commenting out all other tests but the one that was failing. — Ashutosh Jindal, Apr 24 '13 at 10:47
What if you moved the directory creation code into a static method annotated with @BeforeClass, and then remove the directory in a static method with @AfterClass? (I think there is a way to do it without annotations; I've been using annotations for so long I don't remember offhand.) Then, it wouldn't matter which order the tests in each class run. — user944849, Apr 24 '13 at 13:33

score 0 · Accepted Answer · edited May 23 '17 at 11:59

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.

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.

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 !

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.)

Thanks for all the helpful comments.

Unit test failing due to surefire plugin's forkmode

1 Answers1

Linked