Quicktip! TestNG’s-like junit-dataprovider Instead of JUnit Parameterized Class

We all know JUnit test-classes can be parameterized, which means that for a given set of test-elements the test class is instantiated a few times, but using constructors for that isn’t always what you want.

I’ve taken the StringSortTest from this blog as an example.

@RunWith(Parameterized.class)
public class StringSortTest {

    @Parameters
    public static Collection<Object[]> data() {
        return Arrays.asList(new Object[][] {
                         { "abc", "abc" },
                         { "cba", "abc" },
         });
    }

    private final String input;
    private final String expected;

    public StringSortTest(final String input, final String expected) {
        this.input = input;
        this.expected = expected;
    }

    @Test
    public void testSort() {
        assertEquals(expected, mySortMethod(input));
    }
}

This is pretty darn obnoxious some times if you have multiple sets of data for various tests, which all go through the constructor which would force you to write multiple test classes. TestNG solves this better by allowing to provide separate data sets to individual test methods using the @DataProvider annotation.

But don’t worry, now you can achieve the same with the junit-dataprovider, available on Github. Pull in the dependency with e.g. Maven.

<dependency>
       	<groupId>com.tngtech.java</groupId>
       	<artifactId>junit-dataprovider</artifactId>
       	<version>1.5.0</version>
       	<scope>test</scope>
</dependency>

Above example now could be rewritten as:

@RunWith(DataProviderRunner.class)
public class StringSortTest {

    @DataProvider
    public static Object[][] data() {
        return new Object[][] {
                         { "abc", "abc" },
                         { "cba", "abc" },
         };
    }

    @Test
    @UseDataProvider("data")
    public void testSort(final String input, final String expected) {
       assertEquals(expected, mySortMethod(input));
    }
}

You’ll see: no constructor. In this example it doesn’t have much benefits, except may be for less boiler-plate, but now you can create as many @DataProvider-annotated methods which are fed directly to your @UseDataProvider-annotated testmethod(s) .

Sidenote for Eclipse, if you’re using that IDE, is that the JUnit plugin is unable to map the names of the passed/failed testmethods to the ones in the testclass correctly. If a method fails you’ll have to find it back manually in the testclass (or vote for the patch Andreas Smidt created to get this fixed in Eclipse).

In the mean time, if you’re stuck with JUnit and you’d love to use this feature you’re so accustomed to use with TestNG, go ahead and try the junit-dataprovider now.