Mihály Verhás

> "configuration option", read it again, slowly. 😬 It is very similar to the first draft, to which @nipafx responded as above. I thought there is a difference between "making"...

> > @JoergSiebahn could you share your opinion about this approach? Would this work for you? > > Thanks for asking. For me the [second draft](https://github.com/junit-pioneer/junit-pioneer/issues/623#issuecomment-1099404175) that applies class level...

> > Would using an array for mode work for you? > > Based on the proposed changes, an array would give another option. To me it seems like it...

Going back to your earlier comment @beatngu13 - should we actually ***use*** [`TestInstance.Lifecycle`](https://junit.org/junit5/docs/5.0.1/api/org/junit/jupiter/api/TestInstance.Lifecycle.html) (or, alternatively, its enum values)? EDIT: Hm, well, on second thought, using it directly wouldn't make sense...

Should we update `CONTRIBUTING.md` with the recommendation to use the plugin?

Solution given in original thread looks fairly straightforward. I propose we add this to "ready to get started" in `hack.commit.push`.

Range sources have `@Target([...]PARAMETER)` _only_ because of `@CartesianTest`. Previously this was fine, because the annotations (e.g.: `IntRangeSource`) were discovered "indirectly" by `CartesianTestExtension`, but if going forward Jupiter will also discover...

Could you tell me what the purpose of the extension is? What is the difference between a failing test running but not breaking and a test not running at all?

@Marcono1234 I don't think you need to worry about `@BeforeEach` or `@AfterEach`, since exceptions occurring there are not really part of the tested behaviour. In fact, they explicitly _shouldn't_ be...

Hey @Marcono1234 Regarding this PR: we would like you to switch to `InvocationInterceptor` and fix the merge conflicts - if you are still available to work on this.