Mihály Verhás

Results 21 issues of Mihály Verhás

Sometimes an arguments provider needs to be initialised with an annotation externally before you can call `provideArguments`. It has to implement something like `Consumer` or [`AnnotationConsumer`](https://junit.org/junit5/docs/current/api/org.junit.jupiter.params/org/junit/jupiter/params/support/AnnotationConsumer.html). It'd be nice to...

type: enhancement
status: in progress
component: Jupiter
theme: parameterized tests

GitHub supports the .adoc format. I propose we move all our `.md` files to `.adoc`.

🏗️ type: enhancement
📖 theme: documentation
📢 up for grabs
⚙️ component: Pioneer
🚦 status: waiting for interest
good first issue

Related to #623 so we can move forward with it. @JoergSiebahn could you share your opinion about this approach? Would this work for you? Proposed commit message: ``` ${action} (${issues}...

🏗️ type: enhancement
⚙️ component: Pioneer
🚦 status: in discussion
📖 theme: extensions
merge-ready

As described in [this issue in JUnit 5 proper](https://github.com/junit-team/junit5/issues/2671). I think with version 5.8, it should be relatively straightforward to implement this (with some caveats).

⚙️ component: Pioneer
🚦 status: in discussion
📖 theme: parameterized tests
🏗️ type: new feature

In https://github.com/junit-team/junit5/issues/1558 there was the following comment: > rerunner-jupiter's and JUnit Pioneer's annotations didn't really do it for us either - they both introduced a new annotation for flaky tests...

⚙️ component: Pioneer
🚦 status: in discussion
📖 theme: extensions
🏗️ type: new feature

Related to: #355 `@RetryingTest` should support parameters.

📢 up for grabs
⚙️ component: Pioneer
🚦 status: waiting for interest
📖 theme: extensions

`@StdIo` has a `value` property for providing input for `System.in`. Perhaps it should instead offer more explicit properties for expected output/simulated input. Example: ```java @Test @StdIo( input = { "A",...

🏗️ type: enhancement
📢 up for grabs
🚦 status: in discussion
📖 theme: extensions
good first issue

We could pull out the internals of our extensions, put them in a separate, JUnit-independent project and then have that project as a dependency. In this scenario our extensions use...

🏗️ type: question
🚦 status: in discussion
📖 theme: discovery

[Related JUnit issue](https://github.com/junit-team/junit5/issues/1604). Create an extension that makes multiple parameter resolvers work together. In my mind the extension would define a public interface (e.g.: `ParameterAdapter`) and the extension itself.

⚙️ component: Pioneer
🚦 status: in discussion
📖 theme: extensions
🏗️ type: new feature

We could provide new interfaces (`TimeZoneProvider` and `LocaleProvider`) and a way for the user to pull their own implementation into `DefaultLocaleExtension` and `DefaultTimeZoneExtension`. I.e.: ```java @DefaultLocale(localeProvider = MyLocaleProvider.class) class MyLocaleProvider...

🏗️ type: enhancement
🚦 status: in progress
⚙️ component: Pioneer
📖 theme: extensions