Introduce extension API for modifying ParameterizedTest arguments

[scottjasso]

#1139 was recently fixed, allowing access to ParameterInfo for parameterized tests. However some functionality was intentionally left out:

Changing the array would cause the test method to be called with changed arguments.

I don't think that is a good idea. As far as I can tell, nobody has requested to be able to change the arguments provided to a test method. Thus, I would rather pass a copy of the arguments array to such an extension.

If the community clamors for such support, we could always change that aspect at a later date.

I would like to change the arguments :)

My use case is using junit with kotlin. We have a custom extension for injecting a "TestEnv", passed as a receiver:

@Test
@MyTestExtension
fun TestEnv.testFoo() { ... }

This becomes very difficult with @ParameterizedTest, which always wants to put the arguments first. So instead you need this, which is quite ugly.

@ParameterizedTest
@MyTestExtension
@MethodSource("blah")
fun testFoo(arg: String, testEnv: TestEnv) {
  with(testEnv) {
    ...
  }
}

It would be nice if I could modify the arguments to put the TestEnv first. Some kind of general way to modify the results of ArgumentProviders would be neat.

[marcphilipp]

I don't think modifying the arguments is what you're really after. To me, it sounds more like you'd want to somehow signal to the parameterized extension that it should not claim the TestEnv parameter which sounds related to #1945 although with the opposite intention. Would you agree?

[marcphilipp]

For @ParameterizedTest specifically, one option would be to add an offset annotation attribute which would default to 0 and could be set to 1 in this case.

Another option would be to introduce a @NoParameter (or similar) annotation for method parameters that would signal that this parameter resolver should not be resolved using the @ParameterizedTest arguments.

[scottjasso]

I think an explicit annotation-based approach is a little difficult / verbose to use for receivers:

fun @receiver:NoParameter TestEnv.foo(arg: String) { ... }

It does sound similar to Spring's idea -- some kind of DI system for tests -- but yes, the fact that the @ParameterizedTest args have to come first make it more difficult. The offset idea could work, so that it just works like any other ParameterResolver. It may need to be higher than 1 though. For example, using context receivers (or context parameters):

context(TestEnv, DslScope)
@Test
fun testMyDsl() {
   ...
}

I still think a flexible system for mutating the Stream<Arguments> would be nice, though. You could potentially add more Arguments to create more test cases (think cartesian product testing), convert or aggregate arguments without requiring an explicit annotation, inject additional parameters, etc.

[kaipe]

I think an explicit annotation-based approach is a little difficult / verbose to use for receivers:

... ... ...

I still think a flexible system for mutating the Stream<Arguments> would be nice, though. You could potentially add more Arguments to create more test cases (think cartesian product testing), convert or aggregate arguments without requiring an explicit annotation, inject additional parameters, etc.

What you have in mind is achievable by using LazyParams. It allows you to introduce parameters in midair during the test-execution:
https://github.com/lazyparams/lazyparams
The first-page documentation only concerns parameter-introduction inside your @Test methods - but parameters can just as well be introduced inside a @BeforeEach method or by a customized Jupiter extension. This also means the parameterization is independent of those JUnit lifecycle method signatures that seem to be troubling you.