Provide fixed data sets directly in annotation

[janschaefer]

The junitparams JUnit runner provides a way to define simple fixed data sets directly in the @Parameters annotation:

@Parameters({ 
            "17, false", 
            "22, true" })
public void personIsAdult(int age, boolean valid) throws Exception {
    assertThat(new Person(age).isAdult(), is(valid));
}

This is very useful for simple, fixed data sets as it does not require in these cases to define an additional method. It would be great if the junit-dataprovider would also supports this feature!

[aaschmid]

Hi Jan, I am really not sure about this feature because it feels like a very dirty hack! Especially because of

• no possiblility to define an Object arrays
• it is not allowed to define a two-dimensional array.
• it requires to use a lot of IMHO ugly auto-boxing in the code which makes some parts really not easy understandable.

But maybe I am just to conservative, you can see yourself on branch provide.data.directly.in.annotation (SHA: d89681d).

Does this go in the right direction? Is that what you have requested?

[janschaefer]

It goes into the right direction yes :-). Your solution requires some more characters to type and is also a bit harder to read than the solution from junitparams.

{ "a1", "a2", "a3", "b1", "b2", "b3" } vs { "a1, a2, a3", "b1, b2, b3" }

why don't you want to just parse the string and split it by comma? To your other concerns: yes it is not really nice, but it is somehow a pragmatic solution for the simple cases.

[aaschmid]

I am not convinced by the feature at all ... Hm ... splitting by commas seems more elegant, however I am a fan of formatting parameters, e.g.

    @Test
    // @formatter:off
    @DataProvider({
            ",                 0",
            "a,                1",
            "abc,              3",
            "veryLongString,  14",
        })
    // @formatter:off
    public void testStringLength(String str, int expectedLength) {
        // ...
    }

How could this be done, considering strings containing spaces at the beginning or end?

[janschaefer]

ok, I see your point. That is not easily possible in that case. However, it is not necessary to cover all possible cases, because you can always fall back to using a static method as the data provider.

[aaschmid]

Ok, so you also prefer trimmed strings over no possibility to formatting the comma-separated strings?

[janschaefer]

yes, I guess so :-). I think it will not be good if strings are not trimmed, because then something like "a, b" is different to "a,b" which is surprising to me, so I would avoid this. One could think of using single quotes for strings with spaces like this: " ' a ', ' b' ". But then you need a mechanism to escape the single quotes in case you actually want to have single quotes in the strings. This seems to be overly complicated only to support non-trimmed strings.

[aaschmid]

We could additionally allow primitive wrappers, enums as types ....

Any opinions and further suggestions?

[janschaefer]

Wow, that is already great :-). Enums would also be very useful indeed :-). Primitive wrappers would be useful to support null values.

[aaschmid]

Yes, nulls but they make even make the code more complex ... I should probably think about some refatorings ...

[aaschmid]

I am just a bit skeptical because of converting String "null" to a null value? Is this exception intuitive any more?

[janschaefer]

Good point. I think either way is ok, maybe it is more consistent to treat the null string always as a null value even if it is a String. In addition, I guess, in 99% of the cases you really want to have a null String and not a "null" String.

[aaschmid]

You are the boss, it was your feature request :-)

[janschaefer]

Cool :-)

[aaschmid]

:-) As I cannot provided support within the next 4-5 weeks, I will release it afterwards, ok?

[janschaefer]

Sure, it is your project ;-)

[aaschmid]

No, I am just the main contributor and maintainer but it's a TNG project ;-) Oh, and have you heard, #10 is fixed since Eclipse 4.4 M7? :-)

[janschaefer]

Yes, I heard of it :-). I am looking forward to Eclipse 4.4!

[aaschmid]

Hi Jan, what do you think about some additional options like convertNulls and trimStrings as Options in @DataProvider. Would that make it clearer at some points?

[janschaefer]

Definitely a great idea! Then the user can decide what she wants :-)

[aaschmid]

Ok, see issue #24