according to the <native sample>, all targets but ...

# kotest-contributors

[Bernd Prünster]

according to the native sample, all targets but the JVM require kotest-framework-symbol-processor. however that artefact does not exist (see dead link). I don't want to sound ungrateful, because I really am not. But you guys are making it literally impossible to test the new KSP-based implementation if you don't explain how to do it. So please, once again: How do I need to set up a project to try out M5 with KMP projects?

[Bernd Prünster]

I really, desperately want to try out the new runner. the next EAP champions round just started and I have not been able to participate ever since the first Kotlin 2.2.0 EAP. I tried with an MWE but either no tests are received, or if I try to add the kotest-framework-symbol-processor, gradle rightfully complaints that it does not exist. What do I need to get going???

[Bernd Prünster]

@Emil Kantis maybe a simple publishing issue?

[Emil Kantis]

Sorry, yeah there's been a few cases of particular artifacts not being published due to not being configured properly. KSP is on the way out right now

[sam]

My apologies too on the slowness of getting back to you. Been a very busy week at work

[Bernd Prünster]

It's fine, you owe me nothing and I do know how it is. I appreciate the work and all the effort that went into all of it. The real issue in my opionon is that there certainly is a lot of brainpower at work, but little of all that knowledge is externalised wrt. how to actually get going with M5. As soon as the artefacts are out, I can test for myself and report back. It was this situation of wanting to contribute by testing but not knowing how due to lack of info that was frustrating

[sam]

That makes sense

[Bernd Prünster]

Since I overlooked the ksp dependency for my first try: maybe the Kotest plugin should report an error for Multiplatform projects if ksp is not present and the ksp deoendneices are missing. I could draft a PR for that. (pulling the ksp dependency in automatically would only work if locking versions is fine)

[Bernd Prünster]

🎉🎉🎉

[Bernd Prünster]

Woohoo! a failing test on iOS as it should be. No proper test reports yet, but good enough for the moment. Since I'll have to integrate auto-wiring of the ksp stuff into our conventions plugin anyhow, I'll be adding those bits and pieces to the kotest gradle plugin and open a PR. Thanks guys, for everything!

[Bernd Prünster]

js seems not to run, but this could also be a project configuration issue

[sam]

Did you set it up for nodejs? Or just browser

[Bernd Prünster]

NodeJS. But the project is on GitHub, so any pointers are welcome: https://github.com/JesusMcCloud/KMPotest

[Emil Kantis]

Re: version pinning and automatically adding the symbol-processor.

Wouldn’t that be fine? We will release the gradle plugin with each kotest version either way?

[Bernd Prünster]

I'm still fiddling locally. With some constraints to simplify stuff, I should get something going

[Bernd Prünster]

FYI: Draft PR for auto-setup of symbol processing done: https://github.com/kotest/kotest/pull/4938. Needs some cleanup with version pinning etc. and still has a TODO in there to get rid of manually adding the JUnit runner on JVM

[Emil Kantis]

IMO the plugin shouldn’t do any cross-project configuration. It breaks project isolation.

Users should apply the Kotest plugin to all projects, either by hand or using a convention plugin

[Emil Kantis]

But it’s a nice start. I’ll see if I can take it further. Does anyone disagree with the plugin adding the dependency?

[Bernd Prünster]

you mean, it should not check the root project but only the current project for KSP?

[sam]

it should add the dependency but only for that module I think, like Adam said that's best practice for gradle now

[Bernd Prünster]

you want to add the JUnit Runner for JVM targets automatically too? or go for a consistent implementation on all targets based on my draft?