Motivation, Distinction and FAQs

JUnit dataprovider was created to improve writing data-driven test cases using JUnit4. The JUnit5 support added in v2.0 was a logical step for providing native support for JUnit5 adopters as well as extending the already enhanced JUnit5 possibilities even further.

What is the advantage compared to JUnit4 Theories?

Test cases for JUnit4 Theories are built from all data points whose type matches the method's argument – or even the cross product of all matching data points, if the method takes several arguments. The junit-dataprovider, however, addresses another use case: Its test cases may consist of multiple parameters that belong together, which may contain test input values and/or expected values to assert the result. Furthermore, a test method using JUnit4 Theories fails or succeeds entirely (for all data points), on the contrary the junit-dataprovider considers each row of the data provider as standalone test case.

Why can I not use JUnit4 Theories and data points containing DTOs for test cases?

Of course, this is also a possible way to use JUnit4 Theories, constructing DTOs for every single data point causes a lot of boiler plate code and inconvenience. This is AFAIK also the case when you use the ParameterSupplier feature of JUnit4 Theories, where you additionally need a custom Annotation and a class...

But why does JUnit4 not support data providers?

They do, having another name for it, tough, just see Parameterized. The advantage of this concept is surely that it is completely typesafe. But unfortunatly one has to create a class per data provider or parameterized test, respectively, which is IMHO also overkill. The tests of a single unit (i.e. class) have to be divided into different classes, which need to be maintained (renamed, moved etc.) separately. Furthermore, Parameterized tests (even if there are more than a single test method within one test class) can only be executed altogether for a test class. A JUnit dataprovider test, though, can be executed independent on test method level (even if the same data provider is reused for more than one test method).

Is it possible to execute a junit-dataprovider test method for a single test data row?

Unfortunately this is not possible directly except if the other test data rows are commented out in the source code. The rerun of a single test data row, though, is working, if e.g. in Eclipse you right click the test to be executed and choose run/debug.

Why must a @Dataprovider be static while similar junitparams does allow it non-static?

To answer this question we have to look into the internal implementation of [JUnit][]. Its first step is to determine all test methodes to run, before validating and filtering it. At this points of execution, though, no instance of the test class is instanciated. Then as a second step [JUnit][] creates a single instance of the class under test for every single test method. One possibility, for sure, is that junit-dataprovider could create an instance and invoke the @DataProvider as [junitparams][] does interally, but neither @Before nor MethodeRule is minded. Therefore, I decided to disallow a @DataProvider instance methods that nobody using junit-dataprovider believes accessing data of a test class instance is possible.

Note: @ClassRule are currently not executed before the static @DataProvider method because of problems due to internal JUnit4 implementation which is different to the implementation for @BeforeClass.