Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create @Flaky extension #586

Open
Michael1993 opened this issue Jan 28, 2022 · 3 comments · May be fixed by #794
Open

Create @Flaky extension #586

Michael1993 opened this issue Jan 28, 2022 · 3 comments · May be fixed by #794

Comments

@Michael1993
Copy link
Member

In junit-team/junit5#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 which replaces the @Test annotation. This is less than great for two separate reasons:
(1) When we want to disable a test, we don't go and replace the @Test annotation with a @DisabledTest annotation - we add the @Disabled annotation next to the @Test annotation. Having flakiness annotations behave differently is inconsistent.
(2) When you want to mark a @ParameterizedTest as flaky, now you need yet another annotation. (And this will compound the more things you want to annotate about the test, or the more ways you have of running a test.)

Technically, we can accommodate this request. Currently @RetryingTest stores run results in a test-level ExtensionContext::Store. If we elevate this to the class-level, it's possible to store the result of a @Test and re-run it using a test template. Alternatively, we check with an ExecutionCondition if the test template ran first and abort the @Test if it were already successful.

Is it ugly? Yes. For example, if the user specifies that the test should re-try 3 times, then the test template has to run at most 2 times because it runs once as a @Test. Ouch. Also, you have to do a bit of magic to ensure whether you are currently evaluating a test template or a @Test result.

Alternatively, we could introduce a @SelfDestruct annotation that deletes a test if it fails. Java::Geci to the rescue?

@Bukama
Copy link
Member

Bukama commented Feb 5, 2022

@nipafx @beatngu13

@Michael1993 and me talked about this on a team meeting you could not attending, so discussion needed :)

@beatngu13
Copy link
Member

beatngu13 commented Mar 29, 2024

(1) When we want to disable a test, we don't go and replace the @Test annotation with a @DisabledTest annotation - we add the @Disabled annotation next to the @Test annotation. Having flakiness annotations behave differently is inconsistent.

Makes sense. Does that also mean we would deprecate @RepeatedTest as @FlakyTest would be the new way to go (as the PR title of #794 suggests)? Are they functionally equivalent?

(2) When you want to mark a @ParameterizedTest as flaky, now you need yet another annotation. (And this will compound the more things you want to annotate about the test, or the more ways you have of running a test.)

Without looking at the current implementation in the PR, does @FlakyTest also address #405?

@Bukama
Copy link
Member

Bukama commented Mar 31, 2024

(2) When you want to mark a @ParameterizedTest as flaky, now you need yet another annotation. (And this will compound the more things you want to annotate about the test, or the more ways you have of running a test.)

Without looking at the current implementation in the PR, does @FlakyTest also address #405?

As far I got into the code (it has been a while) it's only for regular test, but not for parameterized ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants