Setting environment variables to non-constant expressions

Recap #369:

Annotation values must be constant expressions. That is:

@ClearSystemProperty(key = "must be a constant expression")

A user may have to set a system property to a value that is not a constant expression. In that case, they can still leverage the restore mechanism of our system property extension:

@ParameterizedTest
@ValueSource(strings = { "foo", "bar" })
@ClearSystemProperty(key = "some property")
void test(String value) {
	System.setProperty("some property", value);
}

So while there is a workaround for this in the case of system properties, there is none (to my knowledge) for environment variables. A use case for this (see Stack Overflow):

The https://junit-pioneer.org/ alternative requires environment variable values to be known at compile time. The above [using System Stubs for JUnit Jupiter] also supports the setting of environment variables in the @BeforeAll [we do this too], which means it interoperates well with things like Testcontainers that might set up some resources needed by child tests.

To support this, we could provide something like:

@ParameterizedTest
@ValueSource(strings = { "foo", "bar" })
@ClearEnvironmentVariable(key = "some property")
void test(String value) {
	EnvironmentVariable.set("some environment variable", value);
}

Internally, we currently do this using the non-public class EnvironmentVariableUtils.

What do you think?

[kiview]

To give a concrete example, a user might need to inject the result of getJdbcUrl() into their SUT after the container has started. However, the way by which the value needs to be injected is specific to their SUT or framework and independent from using Testcontainers (and outside of the responsibilities of Testcontainers).

[nipafx]

I agree that referencing a method may be too limiting and it’s pretty boilerplatey. Also, it would be nice to bring our resetting machinery to the table. What about this?

• provide arguments for parameters of type SystemProperties and EnvironmentVariables
• they can be used to clear and set properties/variables
• on clear and set, they store the initial value and reset it after the method

That would also alleviate the need for @Clear... on top of the method. Although we still need some way to apply the extensions…