QuarkusComponentTest: support parameterized test methods

[mkouba]

• arguments of a parameterized test method that are provided by an ArgumentsProvider must be annotated with SkipInject

[Ladicek]

Looks good, but it makes me think about:

• @RepeatedTest (https://junit.org/junit5/docs/current/user-guide/#writing-tests-repeated-tests)
• @TestTemplate (https://junit.org/junit5/docs/current/user-guide/#writing-tests-test-templates)
• @TestFactory (https://junit.org/junit5/docs/current/user-guide/#writing-tests-dynamic-tests)

Out of these, at least @RepeatedTest should work out of the box if we added the annotation to isTestMethod(). The other two are likely more complex.

[mkouba]

Looks good, but it makes me think about:

* `@RepeatedTest` (https://junit.org/junit5/docs/current/user-guide/#writing-tests-repeated-tests)

* `@TestTemplate` (https://junit.org/junit5/docs/current/user-guide/#writing-tests-test-templates)

* `@TestFactory` (https://junit.org/junit5/docs/current/user-guide/#writing-tests-dynamic-tests)

Out of these, at least @RepeatedTest should work out of the box if we added the annotation to isTestMethod(). The other two are likely more complex.

That's a good point. It's not a goal to support all features provied by JUnit though.

@Ladicek would you care to add the @RepeatedTest support (and test) in this PR?

[manovotn]

@Ladicek would you care to add the @RepeatedTest support (and test) in this PR?

Is there a reason why we keep the injection just to test methods? The ParameterResolver allows to do the same for before each callbacks etc., we might be able to do that just as well, right?
Perhaps the only one that doesn't make sense would then be test instance c-tor injection.

[Ladicek]

I can tackle @RepeatedTest, sure. That seems fairly easy and a good thing to have.

[github-actions]

🙈 The PR is closed and the preview is expired.

[Ladicek]

Added a commit for repeated tests support. Turns out we already ignored a parameter of type RepetitionInfo, so I just had to modify isTestMethod to recognize the @RepeatedTest annotation.

[mkouba]

@Ladicek would you care to add the @RepeatedTest support (and test) in this PR?

Is there a reason why we keep the injection just to test methods? The ParameterResolver allows to do the same for before each callbacks etc., we might be able to do that just as well, right? Perhaps the only one that doesn't make sense would then be test instance c-tor injection.

This could cause some lifecycle issues. For example, if Lifecycle.PER_METHOD is used then you wouldn't be able to inject params of an @BeforeAll method because the container is not started yet...

[manovotn]

@Ladicek would you care to add the @RepeatedTest support (and test) in this PR?

Is there a reason why we keep the injection just to test methods? The ParameterResolver allows to do the same for before each callbacks etc., we might be able to do that just as well, right? Perhaps the only one that doesn't make sense would then be test instance c-tor injection.

This could cause some lifecycle issues. For example, if Lifecycle.PER_METHOD is used then you wouldn't be able to inject params of an @BeforeAll method because the container is not started yet...

Oh right, I didn't realize it's done differently from what we had on Weld 👍

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit b7a6b48.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

⚠️ There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit b7a6b48.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.