Parameter resolution should be more flexible

[helpermethod]

Hi!

Just stumpled over an interesting problem:

While this works

    @FieldSource("parameters")
    @ParameterizedTest
    void should_iterate_over_zip_entries(NodeGroup nodeGroup, @TempDir Path tempDir) throws IOException {
    }

This does not

    @FieldSource("parameters")
    @ParameterizedTest
    void should_iterate_over_zip_entries(@TempDir Path tempDir, NodeGroup nodeGroup) throws IOException {
    }

because JUnit is not able to decide how to resolve the tempDir parameter. Because tempDir is annotated with @TempDir, I would expect JUnit to figure this out.

Is this by design? Would this overcomplicate the parameter resolution algorithm?

[marcphilipp]

Yes, this is by design: https://docs.junit.org/current/user-guide/#writing-tests-parameterized-tests-consuming-arguments-methods

While Jupiter could figure that out @TempDir belongs to a core extension, this wouldn't work for non-core extensions. In order to allow more flexible method signatures, we would need a way to mark/unmark certain parameters to be claimed by @ParameterizedTest, for example a @Parameter or @NonParameter annotation, respectively. Alternatively, the @ParameterizedTest annotation could have a parametersMode attribute with BEGINNING and END values, or similar. While that would offer more flexibility it would complicate the programming model. So far, we weren't convinced it would be worth it.

[helpermethod]

Thanks for the explanation, that makes perfect sense!