# feed

Ben Woodworth

03/01/2024, 5:35 AM
I'd like to announce my new 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 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
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 Prepared testing framework with integrations already! Jump over to the #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 :)
🧪 1
🎉 10
K 9


03/01/2024, 5:56 AM
interesting. the api has the same shape as an internal test util I wrote for my project (non-public),
Copy code
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 😅


03/01/2024, 8:47 AM
Which side effects are you thinking of?
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 (example).
❤️ 1

Ben Woodworth

03/01/2024, 11:18 PM
@ephemient 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 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 😌 Here's the migration from kotest to that original parameterize for anyone who's curious: (link)
and @CLOVIS, the parameterize kdoc notes some restrictions. Though side effects aren't always bad, care should be taken in some scenarios. Fairly similar to 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
for each parameter is held on to (for this, and for reporting in failures)
👍 1