Extend cartesian tests with parameterized record

[nipafx]

When writing a set of cartesian tests, there are cases where all test methods need the same set of arguments. Instead of configuring the argument sets for the cartesian product for each test method separately, the methods could accept a record whose components are annotated accordingly. E.g.:

@CartesianTest
void test(Parameter params){
    // ...
}

record Parameter(
        @Values(ints = { 1, 2 }) int number,
        @Values(strings = { "A", "B" }) String letter) {
}

Implementing this feature would require Java 16+, which is when records were introduced. While it would probably be possible to work around the additions to the reflection API, the @Values annotation would also need to be changed to target RECORD_COMPONENT, which was of course also added in 16.

[nipafx]

A workaround for such tests could be:

• put all test methods with the same argument set in a (nested) test class of their own
• parameterize its constructor arguments and assign the values to fields
• in the test methods, use the fields

Is that currently possible or can it be feasibly implemented? // cc @Michael1993

[beatngu13]

Related (I guess):

junit-team/junit5#878

Would it make sense to wait for Jupiter's design decision(s) for @ParameterizedTest?

[nipafx]

That issue is six years old and even though there have been some promising messages recently, those are also already six months old. I'm ok with us trying our own thing and, if Jupiter comes up with something better that we could adopt, abandoning it.

[nipafx]

Hm, there may be a workaround for the records / Java 17 problem: Just use plain classes. If a cartesian test has a parameter without annotation (or maybe some special annotation), we check that class's constructor(s) and each constructor where all arguments have an annotation that the extension understands, gets folded into the product.

That would mean records would work if a non-compact constructor is added. Not ideal, but workable.

[Michael1993]

I think this can be feasibly implemented, yes.