Hello! How hard would it be to get Strikt running ...

# strikt

[Roukanken]

Hello! How hard would it be to get Strikt running on Kotlin/JS?
As basically only alternative I found for multiplatform that generates such good errors is Atrium - but it's api is ... not that nice

There is that one 2 year old issue that says technically it's only a few files that depend on jvm so it shouldn't be that hard I guess?
I considered even helping out, but my gradle-fu is too low to convince it to build for multiple platforms...

[robfletcher]

I’m honestly not sure which is why I haven’t tackled that issue 🙂

In theory there are minimal Java-specific dependencies in the strikt-core module, although opentest4j is likely one that would need to be refactored out.

Unfortunately my work on Strikt is really driven by my day-to-day job and I have not used Kotlin/JS and am unlikely to any time soon. I’d love any input from the community, but it’s unlikely to be something I’d be able to dedicate a ton of time to.

[christophsturm]

i could work on it.

[robfletcher]

I’d be happy to weigh in and help where I can

[christophsturm]

a first step would be to move all the jvm deps out of the core module. then we convert the core module to use the multiproject plugin instead of the kotlin plugin

[christophsturm]

i think it should even be possible without much file moving

[christophsturm]

but if we want to stick to a standard multiproject directory layout we need to rename main to commonMain and test to commonTest (only in the core module)

[robfletcher]

I don’t think that’s a problem

[christophsturm]

maybe we can replace opentest with something in pure kotlin?

[robfletcher]

yeah, honestly I’m not sure Strikt derives a huge amount of value from that library. Theoretically it’s a standard for test exceptions that makes tool integration easier but I’m not so tied to it that I’d object to replacing it

[Roukanken]

looking briefly at how Atrium handles it, since they probably had same problem
Then they just introduce their own error extending Kotlin stdlib's AssertionError (common/js/jvm one, whichever appropriate in each case)

[christophsturm]

i just noticed the biggest issue is the test runner. minutest is vm only. i use kotest nowadays

[christophsturm]

we could create a new module strikt-nano that is multiplatform and then start moving code there

[robfletcher]

I need to look into kotest

[robfletcher]

oh yeah, I’ve seen that before. Reminds me of some Scala testing framework that I wasn’t very keen on

[robfletcher]

although integrating property based testing is neat

[christophsturm]

i use it only as a test runner, and only with the simplest testing style (FunSpec)

[christophsturm]

it doenst do parallel testing as good as minutest via junit5.

[christophsturm]

but it has a gradle and a idea plugin, so its possible to use it without junit5.

[christophsturm]

in the end i just want tests as lambdas and i want to nest them.

[robfletcher]

I’ve found that tests with lambdas (much as I like them, having been a big fan of Jasmine back when I used to do a lot of JS) are a serious performance issue in IntelliJ

[christophsturm]

i created an idea ticket for that. its much better in kotlin 1.4.20 and they are working on it

[christophsturm]

also it helps to split tests into smaller classes which is always good

[robfletcher]

that’s very true

[robfletcher]

I’m always badgering my team that one main class == one test class is an anti-pattern that stifles refactoring

[robfletcher]

but I still fall into it myself

[christophsturm]

its never the perfect time to split it

[christophsturm]

now i can think of splitting it when i wait for idea to react again 🙂

[robfletcher]

I think you have to be mindful of organizing around behavior / features from the start but that’s a habit that’s hard to stick to. Especially when IntelliJ is like “let me help you create a test for that class you just created”

[robfletcher]

I’ve been tracking this IntelliJ issue and it’s pretty depressing: https://youtrack.jetbrains.com/issue/JBR-2732