A modern programming language that makes developers happier.

kotlinlang

I'd like to announce my new <https://github.com/BenWoodworth/Parameterize|Parameterize> library, which brings a clean and flexible syntax for writing parameterized code.

For parameterized testing, using this means parameters can be declared _as code_ within the actual test body, and even computed dynamically if needed. Failures are comprehensive, with a parameter's variable name and value included. And for frameworks like kotlin.test, tooling-friendly multi-failures can be thrown to comprehensively sum up the test cases. (See the <https://github.com/BenWoodworth/Parameterize|GitHub page> for examples)

Parameterize _is_ written to be flexible, though, and works seamlessly with any type of test framework, with little to no configuration. Or even outside of testing, anywhere you might find unwieldy and hard to follow `for` loops. This is my first time letting it out into the wild so I am excited to see how it is used. Especially with the enthusiasm I've been getting, like the <https://gitlab.com/opensavvy/prepared|Prepared> testing framework with integrations already!

Jump over to the <#C06083PAKEK|parameterize> channel if you have any questions/comments/ideas, and give it a try! Particularly with testing, I think this _could_ have its place in any project. It's been in some of my own for a good while now, and thoroughly testing has been pure bliss :)

interesting. the api has the same shape as an internal test util I wrote for my project (non-public),
```chooseAll(onError) {
    val x = choose(1, 2, 3)
    val y = choose(4, 5, 6)
    val z = choose(7, 8, 9)
    f(x, y, z)
}```

similar caveats about side effects etc., so I imagine the implementation is probably similar (I didn't look)

mine is so small I didn't even consider it worth open sourcing though :sweat_smile:

It took a bit of time to get my head around the proper way to use it to declare tests, but now that I have it's really satisfying to use (<https://kotlinlang.slack.com/archives/C06083PAKEK/p1708780231438989|example>).

<@UJQB4DJF7> That's not too different from how this project came about! Dissatisfied with how clunky and inflexible kotest's property testing was for a kotlinx.serialization format I maintain, rolling out <https://github.com/BenWoodworth/knbt/blob/8e6672ecd1c7413f9a491469f72b0cc889fd5c23/src/commonTest/kotlin/test/parameterize/Parameterize.kt|a very familiar looking parameterize syntax> in its test source set, and tacking on features and failure reporting niceties to the point where it made more sense as its own project :relieved:

Here's the migration from kotest to that original parameterize for anyone who's curious: (<https://github.com/BenWoodworth/knbt/commit/8e6672ecd1c7413f9a491469f72b0cc889fd5c23?diff=split&amp;w=1|link>)

and <@UFGCACPE0>, <https://benwoodworth.com/Parameterize/parameterize/com.benwoodworth.parameterize/parameterize.html|the parameterize kdoc> notes some restrictions. Though side effects aren't always bad, care should be taken in some scenarios. Fairly similar to <https://react.dev/learn/keeping-components-pure#:~:text=React%20assumes%20that%20every%20component%20you%20write%20is%20a%20pure%20function|React's assumption that components are pure> and have the same jsx/hooks for the same props.

Luckily though, it is pretty easy to detect when restrictions are broken, and parameterize does throw breakpoint-friendly failures that clearly share what parameter name was declared, which should've been declared instead, etc. All possible because the `KProperty` for each parameter is held on to (for this, and for reporting in failures)