Motivation, Distinction and FAQs

What is the advantage compared to JUnit Theories?

Test cases for JUnit 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, adresses 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 JUnit Theories fails or succeeds entirely (for alle data points), on the contrary the junit-dataprovider considers each row of the data provider as standalone test case.

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

Of course, this is also a possible way to use JUnit 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 JUnit Theories, where you additionally need a custom Annotation and a class...

But why does JUnit 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 altoghter 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 expect 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 JUnit implementation which is different to the implementation for @BeforeClass.