Junit5: Add support for booleans in @ValueSource

[TWiStErRob]

@ValueSource supports all the primitive types, Classes and Strings, i.e. all the compile time constants, except booleans. This is a motion to fix this gap.

See also #1235 where all the others were added, and where @sbrannen said:

Although it doesn't make sense to support literals of type boolean (since there are only two possible such values)

My argument is: 2 is still more than 1 input that @Test "supports", so I have to use a @ParameterizedTest if I want to execute a test of same setup and expectation for both true and false, e.g.:

@ValueSource(booleans = [true, false])
@ParameterizedTest fun `foo works regardless of`(someOtherSetting: Boolean) {
    sut.someOtherSetting = someOtherSetting
    // setup for foo() omitted

    val result = sut.foo()

    // verify foo() result
}

Deliverables

• [ ] Add support for boolean values via a new booleans attribute in @ValueSource.
• [ ] Introduce appropriate tests in org.junit.jupiter.params.provider.ValueArgumentsProviderTests
• [ ] Document in User Guide.
• [ ] Document in Release Notes.

[sbrannen]

Tentatively slated for 5.5 M1 for _team discussion_

[sbrannen]

FYI: the following is an easy workaround that relies on automatic type conversion.

@ValueSource(strings = { "true", "false" })

[TWiStErRob]

Thanks, that's a neat trick.

If this feature request falls through, please add this workaround to the docs at
https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests-sources

[mureinik]

Huh, egg on my face. @aepfli opened a PR while I was working on mine, about 15 minutes before I pushed mine. I guess I should close #1785?

[sbrannen]

_in progress_ ... and with two competing PRs. 😱

[sbrannen]

Huh, egg on my face. @aepfli opened a PR while I was working on mine, about 15 minutes before I pushed mine. I guess I should close #1785?

Well, since #1784 precedes #1785 numerically, and since they look almost (if not truly) identical, I'm inclined to say that @aepfli won the _race condition_.

But let's leave both PRs in tact for the time being, until we've merged one or the other. 😉

[aepfli]

Sorry for not properly communicating - i thought i give it a try after i saw the tweet, and it looked so straight forward, so i just continued. I was not sure, how i should really proceed. Finally i won a race :D

So for me this was a good start, because i somehow managed to contribute - i even do not bother if mine is not the one who got merged - i see this as a starting point, and well maybe there is something else, you guys think would be suitable for first timers :D - now i have licked blood :D

[sbrannen]

Sorry for not properly communicating - i thought i give it a try after i saw the tweet, and it looked so straight forward, so i just continued. I was not sure, how i should really proceed. Finally i won a race :D

No problem.

We recommend that volunteers first ask in the form on a comment in the issue in order to avoid such race conditions.

So for me this was a good start, because i somehow managed to contribute - i even do not bother if mine is not the one who got merged -

That's the spirit! :)

i see this as a starting point, and well maybe there is something else, you guys think would be suitable for first timers :D - now i have licked blood :D

We have an up-for-grabs label exactly for that purpose.