-
Notifications
You must be signed in to change notification settings - Fork 51
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
Retry plugin fails with kotest framework #93
Comments
@marcphilipp something seems to go wrong in the filtering/selection between Gradle and platform. Could you take a look at kotest when you get a chance please and see if it is implementing this part of platform as we expect. |
Any news here? |
I'm afraid I haven't had time to investigate, yet. It's still on my list, though. |
Is it still on the list? |
Sorry for the delay. I took a look and the problem seems to be that kotest does not use @NikolayMetchev Would you be interested in contributing a PR for that? |
I have asked the kotest channel for help: https://kotlinlang.slack.com/archives/CT0G9SD7Z/p1634897392015500 |
Also there is a kotest plugin for Idea. That can run individual tests but it doesn't go through gradle it runs the following. Not sure if that helps.
|
I'm the author of a different kotlin test runner,(https://github.com/failgood/failgood) that also uses a dsl instead of methods to declare tests, and I think autodetecting test runners and then changing the behavior is not a great way to do this. @marcphilipp are you suggesting to create methodSources for tests even if they are not declared in a method? would that work? |
kotest also has a gradle plugin, so it should probably be supported there. |
No, I wasn't suggesting that and it wouldn't help for kotest. The kotest
If Gradle would somehow support filtering kotest tests that would certainly be preferable. However, I don't see a clear path forward bar reimplementing the kotest |
adding support for tests that are not tied to methods to junit platform would be really great, and imo much better than adding custom behavior for every test engine. isnt the whole point of junit platform not to do that? |
The JUnit Platform supports retries via |
Is it worth opening an issue with Gradle itself? |
Kotest will work for --tests if it is a classname only. So the workaround could be as simple as not including the test/method name in the string. The reason Kotest doesn't support --tests fully is because of the reasons discussed - gradle turns it into a method selector and then doesn't propagate it fully on non method based engines. |
I think it would be a great idea. |
Related to gradle/gradle#19513 |
Using the kotest framework (https://kotest.io/) breaks the retry plugin;
Here is the error message:
Here is a full project that recreates the failure:
kotest.gradle.tar.gz
The text was updated successfully, but these errors were encountered: