Almost all the examples of dynamic tests that I have seen, can be reworked and written using parameterized tests. So, which is a practical scenario where the Dynamic tests are the only option, or at least, better suitable than the parameterized tests.
The only "truly" dynamic test example in JUnit 5 docs is not practical.
Any ideas?
JUnit 5, the next generation of JUnit, facilitates writing developer tests with shiny new features. One such feature is parameterized tests. This feature enables us to execute a single test method multiple times with different parameters.
Only one test runner can execute tests at a time in JUnit 4 (e.g. SpringJUnit4ClassRunner or Parameterized ). JUnit 5 allows multiple runners to work simultaneously. JUnit 4 never advanced beyond Java 7, missing out on a lot of features from Java 8. JUnit 5 makes good use of the Java 8 features.
What is Parameterized Test in Junit? Parameterized test is to execute the same test over and over again using different values. It helps developer to save time in executing same test which differs only in their inputs and expected results.
Annotation Type TestFactory @TestFactory methods must not be private or static and must return a Stream , Collection , Iterable , Iterator , or array of DynamicNode instances.
Unlike DynamicTest
, ParameterizedTest
is not part of the core junit-jupiter-api
but is in a separate artifact named junit-jupiter-params
(see 3.12.1. Required Setup). This is because one of the core principles for JUnit 5 is to "prefer extension points over features" (Core Principles · junit-team/junit5 Wiki).
The JUnit Jupiter API defines how to create and register dynamic tests as an extension point to JUnit while JUnit Jupiter Params defines a higher-level API for defining parameterized tests.
JUnit 5.0 M5 Milestone's theme is currently "dynamic containers and minor API changes". With these expected changes test developers will be able to not only create dynamic tests but trees of dynamic tests (dynamic containers containing other dynamic containers and/or tests) which is something that cannot currently be done with paramterized tests. Such will prove, I think, very useful for creating specification-like tests.
In short, the idea as I understand it is to first release core extension points via "low-level" APIs (e.g. dynamic containers/tests) and then create and encourage 3rd parties to create extensions that leverage them (e.g. parameterized tests).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With