I think we need to discuss the automatic adding of KSP. I tired hte cleaner appraoch @Emil Kantis pushed but for reasons I cannot fathom, JS tests are not running at all

https://github.com/kotest/kotest/pull/4945 fixes backticks for native by switching to kotlin poet

As we're about ready to release 6.0, I've added docs for some of the new features coming in Kotest 6 (more to come, especially one on migration / breaking changes) Would appreciate some proof reading (feel free to open Pr with updates): https://kotest.io/docs/next/framework/concurrency6.html https://kotest.io/docs/next/framework/package-level-config.html https://kotest.io/docs/next/framework/sharedtestconfig.html https://kotest.io/docs/next/framework/project-config.html (updated to explain how it works in 6.0) https://kotest.io/docs/next/framework/isolation-mode.html (new section on instance per root and deprecated leaf/test instance)

has publishing been working ok @sam?

The KMP setup pages have been updated for 6.0 https://kotest.io/docs/next/framework/project-setup.html

6.0.0.M8 is being released

M8 is looking solid with the latest intellij plugin

kotest-intellij-plugin-1.3.0-SNAPSHOT-2025.1.zip

Can we help flush out https://en.m.wikipedia.org/wiki/Kotest

just to confirm: automated JUnit XML reports for native and JS are not yet in M8, right?!

Should the kotest-bom have been published? I can't seem to find it since M4

Started a 6.0 release notes doc here: https://github.com/kotest/kotest/blob/master/documentation/docs/release_6.0.md

I finally stitched together a clean-and-simple, stand-alone KMP project with manual wiring of the provided JUnit XML reporter here. As you can see, it doesn't nearly produce enough test reports either on macos or on linux. there should be two report files per platform, but if you check the "List reports" output of both jobs, you'll notice two rather lonely files created by the linux test run and eight somewhat less lonely files created by the macos runner. Things don't really get better when adding the junit runner, except that jvm test reports start appearing. so my question is: how to run tests on all targets?

@sam just seen M9 kick off - but I think kotest-assertions-table and the new decoroutinator extensions are missing from the nmcp aggregations

I am kicking off a new 🧵 for browser-based tests. In browser environments, using SystemFileSystem will result in a hard fail (runtime exception). So how does kotlin.test handle it? I don't know but I have a really hacky Idea how we can make it happen: • Start a webserver on a random port (or specify it in the test config) • Let the test runner in the browser push test results to the web server • Let the web server save the reports to disk • ??? • Profit So this hard fail could explain why my prototype didn't even show tests being run, id the file system is accessed early enough. (I'm now AFK for 2-3 hours)

In case someone has the capacity to prepare a PR (I currently don't): there's still lots of `println`s in the gradle plugin used for debugging, when it really should be

project.logger.log(…)

. Functionally, this is irrelevant for the 6. release, but a cleanup wouldn't hurt. Just to clarify: I'm not talking about the console reporter, but lines like these

I'm going to make this change for 6.0 (like right now), let me know if anyone thinks its a bad idea (could revert it) but a breaking change (slightly breaking change) I'd like to get into 6.0 final https://github.com/kotest/kotest/issues/3346

I am releasing M17 which will be the last milestone

unless I see any blockers on this it'll go to 6.0 final

hi folks, I'm going to post some simple PRs to https://github.com/kotest/kotest-examples/ to update it, to hopefully reproduce an issue with kotest 6.0.0 I'm seeing in my project (ref). I think it has something to do with Gradle 9, but I'll just try to prove or disprove it via updating the examples, which will be for the benefit for everyone anyway

did nested test support not make it into 6.0? I still see the

Nested tests are not supported

exception https://github.com/kotest/kotest/blob/3197e7de2e4f3f08761aab9eaecc1069bbeb3ba1/kotest-framework/kotest-framework-engine/src/commonMain/kotlin/io/kotest/engine/test/scopes/TerminalTestScope.kt#L16 https://kotlinlang.slack.com/archives/CT0G9SD7Z/p1738894405840939?thread_ts=1738893643.653549&cid=CT0G9SD7Z

Is someone able to retry the failed job on https://github.com/kotest/kotest/pull/5085 or shall I push an empty commit?

am really confused why the windows tests fail most times in PRs but always pass in main. It seems to be using the same config (and I updated the PR workflow to clone the master workflow). https://github.com/kotest/kotest/actions/runs/18655653779/job/53184578443

@sam I've noticed the master builds are broken since my PR-build fix - https://github.com/kotest/kotest/pull/5198 should fix it

6.0.5 is released

Hi fellow contributors! I just wanted to let you know that I'm leaving the GitHub project as a member and proceed as a simple contributor from now on. My main area of expertise was the framework part, but as you know, I have created my own testballoon a while ago and lots of effort now go into that one. Also, Kotest has moved on and central framework parts have changed, so my expertise in this area would be less useful these days. ❤️ It's been a pleasure and honor to be part of this project, and I'd like to thank every one of you for the cooperation over the years, and the positive vibes at all times. I'll be happy to contribute to the Kotest Assertions library in the future whenever that makes sense. Keep on moving the testing space forward!

A short write-up about functional programming, test doubles, and fakery https://github.com/kotest/kotest-cookbook/blob/master/README.md#using-fakery WDYT?

The property modules take forever to compile (as there's lots of slow type inference going on with multiple type parameters). Its one of the main reasons the PRs take forever and its frustrating when we have multiple PRs queued up that they take an hour apiece. What do you think about moving properties out to a separate repo: • they don't get as much development as assertions/framework because they are largely "complete" • they don't really interact with the assertion/framework modules in the way those two do with each other • we keep the same group/module ids so users don't need to update anything ◦ we just have to make sure when we release x.y.z of the main repo we release x.y.z of property test too, no big deal ◦ snapshot builds wouldn't align but not sure how many people are running snapshots Thoughts?

Why have we removed the "Bug" label?

I don't think we like this way of speaking. Next time I suggest closing the issue as not planned and mute/ban the user for some days It's free work being done, nobody deserves this