SetSystemProperty / SetEnvironmentVariable broken for nested classes

Looks like 3ecf1338f552d99a5192999ee142d09760413d78 had the side effect of breaking SetSystemProperty and SetEnvironmentVariable when used in nested classes. Example for SetSystemProperty:

@SetSystemProperty(key = "PROP", value = "PROP-VALUE")
class NestedSetSystemPropertyTest {
    @Nested
    @TestMethodOrder(MethodOrderer.OrderAnnotation.class)
    class nested {
        @Test
        @Order(1)
        void worksAsExpected() {
            assertEquals("PROP-VALUE", System.getProperty("PROP"));
        }

        @Test
        @Order(2)
        void breaksUnexpectedly() {
            assertEquals("PROP-VALUE", System.getProperty("PROP"));
        }
    }
}

This is due to SystemPropertyExtension.entriesToSet() now only returning the property “PROP” for the outermost ExtensionContext in AbstractEntryBasedExtension.beforeEach(). While this is fine during the setup phase (beforeEach/beforeAll) during tear-down AbstractEntryBasedExtension.restoreOriginalEntries() uses ExtensionContext.Store.get() to return the matching EntriesBackup: https://github.com/junit-pioneer/junit-pioneer/blob/3ecf1338f552d99a5192999ee142d09760413d78/src/main/java/org/junitpioneer/jupiter/AbstractEntryBasedExtension.java#L149-L151

Note that ExtensionContext.Store.get() has the following documented behaviour:

If no value is stored in the current ExtensionContext for the supplied key, ancestors of the context will be queried for a value with the same key in the Namespace used to create this store.

So although the inner class and inner methods have no EntriesBackup, AbstractEntryBasedExtension.restoreOriginalEntries() grabs the outer context’s instance during tear-down of worksAsExpected(), which accidentally clears the properties for the breaksUnexpectedly() test.

It would be great if ExtensionContext.Store were to provide a way to only query the store of the provided context and not the ancestor stores too. Haven’t come up with an elegant solution for this yet. A workaround could be to store something that identifies the originating context within EntriesBackup on creation and to only restore an EntriesBackup-instance if the current context matches the originating context.

(Our workaround is to pin the junit-pioneer version to 1.4.0 for now.)

[beatngu13]

So, I investigated that issue and can confirm that this indeed is a problem. But thanks to your excellent analysis (kudos!), it wasn’t that hard to come up with a quick fix. As you already pointed out:

A workaround could be to store something that identifies the originating context within EntriesBackup on creation and to only restore an EntriesBackup-instance if the current context matches the originating context.

I did this:

https://github.com/beatngu13/junit-pioneer/blob/0788c6276e7bc647821b080ba4aa92314cfae345/src/main/java/org/junitpioneer/jupiter/AbstractEntryBasedExtension.java#L155-L157

Determining the store key via the display name of the current test or container seems to do the trick.

Would you mind giving this a try? You can obtain my fork’s branch as a dependency e.g. via JitPack:

<repositories>
  <repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
  </repository>
</repositories>

<!-- ... -->

<dependency>
  <groupId>com.github.beatngu13</groupId>
  <artifactId>junit-pioneer</artifactId>
  <version>issue~480-nested-sysprop-envar-SNAPSHOT</version>
</dependency>

[nipafx]

I just released 1.4.2 with the fix. I’m sorry it took 2.5 weeks (particularly after @beatngu13 created the fix in a day). 😔