Add @SpringTest annotation to bootstrap integration with the type's lifecycle and features similar to standard Spring components

[odrotbohm]

As a follow up of #22286, this ticket is supposed to discuss the idea of a canonical annotation to be used with test classes that constitute Spring integration tests and configure JUnit to treat the class like a Spring component as much as possible. In detail, this includes:

• The instances of the test class are singletons by default
• Dependency injection (esp. constructor injection) works just as for Spring components

This could effectively look something like this (name TBD):

@SpringJUnitConfig // Bootstrap Spring container
@AutowireTestConstructor // Enable constructor injection
@TestInstance(Lifecycle.PER_CLASS) // Singleton, i.e. one instance for all test method invocations
// other annotations needed
@interface SpringTest { // SpringTest as that's in line with @SpringBootTest
  // add aliases for attributes of above annotations
}

The goal is to minimalize the conceptual differences between a Spring component in production code and a integration test class.

[marcphilipp]

Out of curiosity, why make @TestInstance(Lifecycle.PER_CLASS) the default? It imposes an additional burden on test authors to manage state correctly and prevents test methods within the class from being executed in parallel.

[odrotbohm]

Because singleton is the default scope for Spring components in general. Making this the default for tests, too, is just consistent with that. This creates the incentive to create stateless classes, or classes whose methods do not share state, which not only enables multithreaded execution much easier but is also more efficient as it avoids the need to create new instances of the class for each method invocation. There's no burden to manage state if you don't have any.

I know that JUnit's default has been exactly the other way round, but I've always considered the reinstantiation a workaround to allow state in the class. Coming from a pure Spring mindset it feels odd that we teach users to write stateless, immutable components but then all of a sudden allow keeping state in the test classes. Especially beginners usually don't realize this difference clearly and then start to use the pattern of manipulating instance variables from within production components which leads to subtle, hardly testable problems.

Aligning the testing model with the runtime component model makes problems like these more obvious and discoverable more easily.

[sdeleuze]

Big +1 from me on that one, this combination of annotations is exactly what I need for Kotlin developers that typically use non static @BeforeAll / @AfterAll annotated methods and constructor based injection with non-nullable immutable properties.

[snicoll]

Because singleton is the default scope for Spring components in general

Isn't that going a bit too far? The same way that field autowiring in a test class is okay but doing so in a spring component should definitely be avoided.

Given that the constructor is going to be invoked for each test, there is no "state" per se. I personally like to setup the common infrastructure of a test in the constructor so that it is immutable. If you have a single component, it is easy enough to just initialize an attribute as the first line of your test but: a) this is something that we have to repeat for every test, b) it's getting more annoying if you have more than one thing to initialise.

I guess there are arguments to be made to wrap that in a component or whatever but I think we should be a bit more pragmatic and keep the default of the test framework.

[odrotbohm]

Isn't that going a bit too far? The same way that field autowiring in a test class is okay but doing so in a spring component should definitely be avoided.

How do you mean "too far"? Having to inject dependencies into fields was a necessity as previous JUnit generations didn't support constructors. You're also free to use field injection with tests, the annotation setup doesn't change that. It's all opt-in anyway. The annotation enables constructor injection, it doesn't enforce it. Just like @Component does.

Given that the constructor is going to be invoked for each test, there is no "state" per se. I personally like to setup the common infrastructure of a test in the constructor so that it is immutable. If you have a single component, it is easy enough to just initialize an attribute as the first line of your test but: a) this is something that we have to repeat for every test, b) it's getting more annoying if you have more than one thing to initialise.

I am not sure I can follow. The per-class setting changes that to instantiate the test class only once. If you have an immutable test fixture that's valid for all tests you can still set that up in the constructor. That can then be augmented by additional setup done in the test methods. If you have common logic there, you can still extract methods which you call from some methods and not from others.

It all just creates more incentives to work with immutable test classes, which is a good thing in general and – as indicated before – all of this is optional.

I guess they are arguments to be made to wrap that in a component or whatever but I think we should be a bit more pragmatic and keep the default of the test framework.

Again, I can't follow. It's an annotation that's optional to be used. When you use it, you opt into its features. If you don't want that, don't use the annotation, use the ones you'd like to apply. I think it's convenient – or: pragmatic – to have a one stop shop annotation that expresses: this test class behaves like a Spring component in terms of lifecycle. If I want the defaults, I get them by default anyway. Especially for beginners this removes a lot of cognitive overload because you don't even have to talk about lifecycles and the differences between them in Spring VS. JUnit.

Someone creates an instance, calls all @Test methods on it, done. Not: someone creates an instance, calls one method, but then – because you might have changed state with that method – has to recreate the instance, execute all preparation again, for each method. The latter might seem obvious and easy to us, because we're so very familiar with it. That doesn't mean it's simple though.

[sbrannen]

Because singleton is the default scope for Spring components in general. Making this the default for tests, too, is just consistent with that. This creates the incentive to create stateless classes, or classes whose methods do not share state, which not only enables multithreaded execution much easier but is also more efficient as it avoids the need to create new instances of the class for each method invocation. There's no burden to manage state if you don't have any.

The reason @marcphilipp posed that question is that parallel execution is disabled by default in JUnit Jupiter for methods in test classes configured with per-class test instance lifecycle semantics.

Excerpt from the JUnit 5 User Guide:

The default execution mode is applied to all nodes of the test tree with a few notable exceptions, namely test classes that use the Lifecycle.PER_CLASS mode or a MethodOrderer (except for Random). In the former case, test authors have to ensure that the test class is thread-safe; in the latter, concurrent execution might conflict with the configured execution order. Thus, in both cases, test methods in such test classes are only executed concurrently if the @Execution(CONCURRENT) annotation is present on the test class or method.

[marcphilipp]

@odrotbohm Thanks for the detailed explanation!

@sbrannen Thanks for providing additional background to what I wrote!