https://kotlinlang.org logo
Join Slack
Powered by
the interesting bits are here: <https://github.com...
# minutest
c
that is a multiplatform class so if we use this we have a runner that works on jvm, js and native
so first convert the build to a multiproject lib, then move as much code as possible to common sources, and then implement the kotlin.test framework adapter
we can even write the kotlintest framework adapter before converting to multiplatform.
kotlin.test supports junit, junit5 and testng on the jvm so maybe it can replace the junit adapters
d
Good work
But my goodness that’s confusing. I’m tired now, but I just don’t see the relationship between the different bits in the different frameworks in the different languages.
FrameworkAdapter seems to be a way of thunking from the kotlin.test junit-like classes and annotated functions to an actual test runner like JUnit or Mocha? So not useful to us?
Because we don’t want to be the framework, we want to be the syntax.
If kotest (really?) is multiplatform and has a model that will support minutest then that would be great. And it’s likely that it’s model will support minutest, because they seem to support pretty much every test model that could be devised.
I’m assuming, but can’t currently tell, that kotest has IntelliJ and Gradle and Maven integration, so that if we can generate contexts and tests in its model it will run them and integrate with those runners, plus Mocha etc
c
4.1 has a intellij plugin
from my reading of the docs a kotlin test suite is minutest context and a kotlin.test test is a minutest test, so it could fit pretty easy.
d
Yes, but I’m not convinced that Kotlin.test is any help to us
As the abstractions there seem designed only to let the Kotlin.test annotated methods be invoked by test runners.
5 Views
Open in Slack
PreviousNext
Powered by