-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flow Test Support for JUnit 4 and JUnit 5 [SWF-1740] #915
Comments
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? |
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. |
Sam Brannen commented Regarding the introduction of parallel 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 For JUnit Jupiter, this can be achieved via an extension that is registered via 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 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 |
Sam Brannen commented Actually, Spring REST Docs uses a |
Sam Brannen commented Related to #914 |
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 sameexecution
package, with the package to be removed eventually. A separatesupport
package, next toexecution
, could be the home for JUnit 5 variants.The documentation should also be updated accordingly.
Affects: 2.5.1
Issue Links:
("is duplicated by")
The text was updated successfully, but these errors were encountered: