Make invocation index for @ParameterizedTest available to test author

[gaba-xyz]

Overview

The invocation index of a parameterized test is accessible for templating when setting the display name of the test.

When it comes to accessing the invocation index using TestInfo it is not possible as it looks like the TestInfo implementation for @ParameterizedTest is of the default type. I would expect to get an RepetitionInfo instance so that I can access the invocation index programmatically.

Related Issues

• Provide access to arguments of parameterized tests in lifecycle callback methods #944
• Introduce extension API for accessing arguments of parameterized tests #1139
• Add ability to access the current repetition of a RepeatedTest from afterEach in a custom Extension #1884

[sbrannen]

FYI: this is closely related to #944.

[sbrannen]

Tentatively slated for 5.4 M1 for team discussion

[mschechter-bellese]

It would also be helpful to have the index available in the ExtensionContext, so that it can be used via the @EnabledIf / @DisabledIf handler method.

[marcphilipp]

A non-intrusive way of adding this would be to add the invocation index to ArgumentsAccessor.

@Gabology @mschechter-bellese Would that work in your use case?

[marcphilipp]

Tentatively slated for 5.8 M2 solely for the purpose of team discussion.

[mschechter-bellese]

A non-intrusive way of adding this would be to add the invocation index to ArgumentsAccessor.

@Gabology @mschechter-bellese Would that work in your use case?

Would that make it available to the methods implemented for @EnabledIf / @DisabledIf, so that I can skip specific indexes when running a parameterized test? If so, I think the ArgumentsAccessor would work.

[marcphilipp]

Would that make it available to the methods implemented for @EnabledIf / @DisabledIf, so that I can skip specific indexes when running a parameterized test?

No, ExecutionConditions are currently only evaluated at the method level, not the invocation level so I think that would be a separate issue.

[mschechter-bellese]

Would that make it available to the methods implemented for @EnabledIf / @DisabledIf, so that I can skip specific indexes when running a parameterized test?

No, ExecutionConditions are currently only evaluated at the method level, not the invocation level so I think that would be a separate issue.

Yes, that makes sense. I think I would need a different solution, then. Could you please let me know if there's an existing issue that covers this?

[marcphilipp]

I think #1139 is closely related.

[mschechter-bellese]

I think #1139 is closely related.

Thanks!

[marcphilipp]

Team decision: Add ArgumentsAccessor.getInvocationIndex().

[marcphilipp]

@Gabology @mschechter-bellese Would one of you be interested in submitting a PR for this?

[mschechter-bellese]

@marcphilipp,

I am currently more focused on making the invocation index available to @DisabledIf / @EnabledIf consumers via #1139.

Quick question: if the invocation index is to be accessible from the ArgumentsAccessor, how is the invocation index value provided during instantiation? It appears that the invocation index is only available as an AtomicInteger in ParameterizedTestExtension.provideTestTemplateInvocationContexts, so I'm probably missing something.

[marcphilipp]

Quick question: if the invocation index is to be accessible from the ArgumentsAccessor, how is the invocation index value provided during instantiation? It appears that the invocation index is only available as an AtomicInteger in ParameterizedTestExtension.provideTestTemplateInvocationContexts, so I'm probably missing something.

From there it needs to be passed to ParameterizedTestInvocationContext, ParameterizedTestParameterResolver, and finally ParameterizedTestMethodContext.resolve.

[ghost]

I have the ArgumentsAccessor.getInvocationIndex() idea working on my fork. I'll raise a PR for it.