Introduce configuration parameter for setting default test instance lifecycle semantics

[sbrannen]

Overview

For teams that prefer per-class test instance lifecycle semantics, in order to prevent such teams from having to copy-n-paste @TestInstance(Lifecycle.PER_CLASS) across the code base, it would be beneficial to introduce a configuration flag (e.g., system property) that allows the default test instance lifecycle semantics to be set on a per-project basis (e.g., for a build).

Switching the default semantics would remain an opt-in decision but would be considerably less intrusive with the configuration flag.

See #419 (comment) for background information.

In addition, we could introduce support for setting ConfigurationParameters via a properties file (e.g., a junit.properties file in the root of the classpath). This would allow such configuration to be contained in the project itself (and checked into a VCS) as opposed to having to set such a flag in the build script as well as in the IDE (perhaps on a per test run basis).

Related Issues

• Allow @BeforeAll and @AfterAll methods to be non-static #419
• Enable per-class test instance lifecycle mode by default for Kotlin classes #991
• Use same default lifecycle for Kotlin and Java test classes #1002
• Read ConfigurationParameters from properties file in classpath #1003
• Use junit.jupiter as prefix for Jupiter configuration parameters #1004

Deliverables

• Introduce junit.jupiter.testinstance.lifecycle.default configuration parameter for setting default test instance lifecycle semantics.
  • Introduce new constant in org.junit.jupiter.engine.Constants.
  • Support enum constant names from TestInstance.Lifecycle, ignoring case.
  • Introduce unit tests for the new configuration parameter.
  • Introduce integration tests for the new configuration parameter, including override semantics for local config, config params provided to the launcher, and system properties.
• Log INFO message if the test instance lifecycle mode has been set via the configuration parameter.
• Update JavaDoc for @TestInstance.
• Update User Guide.
• Update release notes.

[sdeleuze]

Strong +1 for this one and not only from a Kotlin developer perspective, to me @TestInstance(Lifecycle.PER_CLASS) makes sense as the default behavior in Java as well. Since it seems not possible to set that as the default in JUnit 5, being able to set such default globally would be super useful.

[sdeleuze]

Since this issue has been postponed to 5.1 backlog (I can understand there is some concern introducing a different mode of execution of the tests based on configuration), I was wondering if we could find a better alternative solution.

For example, can't we turn this issue into enabling automatically PER_CLASS on classes with non-static methods annotated with @BeforeAll and @AfterAll rather than just failing in such case?

[sbrannen]

For example, can't we turn this issue into enabling automatically PER_CLASS on classes with non-static methods annotated with @BeforeAll and @AfterAll rather than just failing in such case?

That's certainly an interesting idea.

But I'm concerned that it would come as a surprise to developers who simply forgot to type static but meant to.

@junit-team/junit-lambda What do the rest of you think?

[smoyer64]

it would come as a surprise to developers

I agree - I think feature switches that change the default behavior should be specified explicitly.

[sdeleuze]

Ok, I understand.

Is supporting @TestInstance(Lifecycle.PER_CLASS) at package level something we could consider?