this goes out to all the test enjoyers <https://co...

# test

[jessewilson]

this goes out to all the test enjoyers
https://code.cash.app/burst-test-interceptors

[Zach Klippenstein (he/him) [MOD]]

It looks like it’s possible to use this without the parameterization features of Burst - as awesome as this looks (I’ve wanted it in compose so bad), I’m not sure now if burst is becoming a general testing framework?

[jessewilson]

I was gonna do it as a 2nd project

[jessewilson]

But I took a shortcut and added it to Burst cause they're complementary

[jessewilson]

I don't anticipate more Burst features at the moment. We've already got all the JUnit stuff I use

[jessewilson]

I would like to convince @bnorm to promote this stuff into kotlin.test

[jessewilson]

It also fits well with power assert!

[CLOVIS]

This uses code generation, right?

[CLOVIS]

It seems it has the same caveats as JUnit as described in https://ivan.canet.dev/blog/2025/06/17/state-of-kotlin-tests.html#fixtures

[CLOVIS]

Ah no, it allows co-locating setup and tear-down, so it is better than Junit, nice!

[jessewilson]

Ooooh that’s a great resource

[CLOVIS]

If you want, I could add Burst & co to it, but;
• I definitely won't have time for that in the coming month…
• The article is already very long

[jessewilson]

No problem! It’s reassuring to know what stuff kotlin.test is still missing

[CLOVIS]

Ahah there's a lot

[jessewilson]

Dynamic tests is the big one.

[CLOVIS]

Yes, that and no suspend in @Before /etc

[Oliver.O]

Another big one: Finegrained, cross-test concurrency. I'm just analyzing use cases with testballoon TestBalloon, can be such a great time saver.

[Oliver.O]

If you can have dynamic multiplatform testing plus all your favorite integrations (Android instrumentation, JUnit rules, Compose testing), why not write parameterized tests in plain Kotlin?