Flow Test Support for JUnit 4 and JUnit 5 [SWF-1740]

[spring-operator]

Rossen Stoyanchev opened SWF-1740 and commented

Currently the Flow Test support depends on the JUnit 3 class hierarchy preventing applications from upgrading to recent JUnit versions. We need to allow use of both JUnit 5 and JUnit 4.

For the actual execution, we'll likely need to duplicate the base classes from the execution package and deprecate the existing ones. AbstractJUnit4*Tests classes could be added in the same execution package, with the package to be removed eventually. A separate support package, next to execution, could be the home for JUnit 5 variants.

The documentation should also be updated accordingly.

---

Affects: 2.5.1

Issue Links:

• 913 Stop depending on JUnit 3 and upgrade to JUnit 4

  ("is duplicated by")

[spring-operator]

Etienne Dysli Metref commented

Would there be a way, for the new JUnit 5 variant, for developers to avoid having to extend a class from SWF to write their flow tests?

[spring-operator]

Rossen Stoyanchev commented

Maybe the new extension model could provide an answer. It is true that for JUnit 5 we can look to also improve and deviate from the existing implementaiton.

[spring-operator]

Sam Brannen commented

Regarding the introduction of parallel AbstractJUnit4*Tests base classes, that's certainly an option for JUnit 4 support.

However, we might be able to find synergies between JUnit 4 and JUnit Jupiter support.

For example, several projects have introduced testing framework agnostic support classes that can be injected into both JUnit 4 and JUnit Jupiter test classes.

For JUnit 4, this can be achieved via a @Rule.

For JUnit Jupiter, this can be achieved via an extension that is registered via @RegisterExtension.

Going that route would allow for similar (if not identical) programming models for both JUnit 4 and JUnit Jupiter.

If I recall correctly, that's what was done in the Spring REST Docs project.

Another option for JUnit Jupiter is to have the Web Flow test collaborators/configurers injected into the test constructor, lifecycle methods, or test methods via the ParameterResolver API.

In order to make concrete recommendations, however, I'd likely need to experiment with a spike myself.

Let me know if you have any questions...

- Sam

[spring-operator]

Sam Brannen commented

Actually, Spring REST Docs uses a @Rule for JUnit 4: https://docs.spring.io/spring-restdocs/docs/2.0.3.RELEASE/reference/html5/#getting-started-documentation-snippets-setup-junit

  And an extension that implements ParameterResolver for JUnit Jupiter: https://docs.spring.io/spring-restdocs/docs/2.0.3.RELEASE/reference/html5/#getting-started-documentation-snippets-setup-junit-5

  Behind the scenes, both of those serve as a façade to ManualRestDocumentation (which is the testing framework agnostic implementation that was introduced in order not to have duplicated code for JUnit 4 and JUnit Jupiter).

[spring-operator]

Sam Brannen commented

Related to #914