3 ms·

This is the main reason we have assertion libraries and don't just use boolean expressions. My favorite test framework of all time, rspec-given[1] (by the late

This is the main reason we have assertion libraries and don't just use boolean expressions. My favorite test framework of all time, rspec-given[1] (by the late, great Jim Weirich) solved this a different way by using AST introspection to extract both sides of a boolean expression and give a helpful message even with an assertion like: `Then { result == 7 }` [1]: https://github.com/jimweirich/rspec-given https://github.com/jimweirich/rspec-given

gavmor 2y ago
Thank you! It feels a bit crazy-making to see a post like this published with no mention of eg rspec "matchers", ubiquitous in Ruby land for decades. I'm somewhat dismayed that this even needs to be said in 2024; I'll bet there's an entry in Ward Cunningham's wiki imploring devs to write tests that fail descriptively but—as evidenced by my lack of citations—it's often easier to write a post than search for a post. (And that's part of Joe Armstrong's "The Mess We're In") Edit: to make a non-meta point, these sorts of appeals to "please exhibit good behavior" can't stand against economic forces, eg time constraints and KPIs, so I wonder if there isn't a ToolsNotRules[0] implementation which might enforce more introspective assertions. Edit2: Oh, duh—TDD is the practice which enforces more actionable test failures! After all, an unactionable test failure drives no development. So if you're really keen on actionable failures, try TDD. 0. https://benchristel.github.io/process-to-processes/Fundamentals/ToolsNotRules.html https://benchristel.github.io/process-to-processes/Fundament...