I want to like Kotlin, and a well-written Kotlin codebase can be a beautiful thing, but ugh, do I hate its kitchen sink approach to syntax. You end up with some super odd looking code that reads "natural" under specific expectations, but which is completely inconsistent with anything else you could write, and very undiscoverable.
I'm looking at Mockk's things like
verify { mock wasNot Called }
And it grinds my gears, somehow.
The result is worse than C++ macro madness IMO.
=> More informations about this toot | More toots from zeh@mastodon.gamedev.place
@zeh That looks like it's testing related?
It's the same shit in JS testing frameworks, for some reason they ended up trying to create 'human readable' code, e.g. like this:
it("should not be equal", () => {
expect(thisThing()).not.toBe.EqualTo(...)
}
I have no idea who started this or thought this to be a good idea - but it seems to be a popular thing in the 'unit testing culture'.
=> More informations about this toot | More toots from floooh@mastodon.gamedev.place
@floooh Yeah, you got it, it's for testing.
Honestly, I don't fully mind the "this.thing().toDo(that)" or whatever. Verbose, but discoverable by autocompletion.
In mockk's case, it's not, you have to search for the magical incantation. It "reads" great, but writing is extremely hard. You have to fully know what's possible, and how, beforehand.
Not surprisingly, the documentation is shit since there's no structure to anything.
But it's a bigger problem than Mockk. I see it everywhere with kt.
=> More informations about this toot | More toots from zeh@mastodon.gamedev.place This content has been proxied by September (3851b).Proxy Information
text/gemini