https://kotlinlang.org logo
Join Slack
Powered by
I have a build of the intellij plugin working usin...
# kotest-contributors
s
I have a build of the intellij plugin working using gradle to even run subtests. At the moment gradle is used to run the full class, and for tests, we create a java exec task. By running it all through gradle, things like gradle.properties are correctly applied to tests. It also means we can use the plugin now to run individual KMP tests too, as long as we have a way of applying a filter to only run the selected test. That second step works for the gradle test task because we support the --tests parameter. I'm not sure if the JS / native support provides that. We can also ditch the gradle test task completely if we want and then we are free of the restrictions that come from a class/method based library (ie, things like navigation from intellij's test results window will work). Should we consider this?
l
I like the idea of ditching gradle and maintaining things as our infra mainly
e
Fuck yes. I think not being able to run individual tests using gradle is one of the main pain points for my team.
As for sidelining Gradles infra.. I think we need to play nicely as much as possible, so third party integrations don’t break. I.e. I think our test task needs to report results, support gradle-style filters, etc. I’m wondering if there’s some golden middle way through this where we simply enhance the gradle test task with kotest filters?
s
We've been working with gradle for years and they seem to place low priority on fixing all the bugs that affect us.
We can still support junit5. Just offer our own plugin too.
The junit5 runner is only for JVM anyway
e
What if we just enhance the gradle test task, instead of replacing it? We can remove the IntelliJ TC gradle test listener and add our own writer directly. Not sure if we need to do much else?
Maybe add support for Kotest filters too
Our own writer would fix the navigation I think
s
If we can do that easily then that's an option. Assuming there isn't tons of edge cases we run into.
e
You already fixed a custom writer, right?
s
The TC writer is there
The other thing with gradle test is that we can't make our own convention object to set kotest specific options in a typesafe way
The test filter stuff is all class method speciifc too
e
Can we pass our own filter through a system property perhaps?
And our own extension could customize the gradle test task with Kotest system properties
Could be a really neat way to support doing project config
s
We probably could. But is doing all this harder than just running the launcher from a custom task?
And it's still only going to be jvm specific so we need something for js and native regardless
e
True
Probably a bit harder, given that we need some other solution for non-jvm anyway. But could be worth it so we dont cut off users who use gradle enterprise
s
I think we can keep both. Junit runner but just making ours the preferred way.
e
Sounds good :)
12 Views
Open in Slack
PreviousNext
Powered by