Earlier quoted context omitted.
I'm perfectly happy with assert and assert_eq. The macro isn't deeply magic, it just prints the text of the tokens passed to it (ie foo.bar()) alongside the value. assert_eq can add a diff. Sure the error message isn't perfect, so you stick a console.log or two in your test and run it again if you're confused.
> stick a console.log or two in your test and run it again if you're confused Falling back to manual debugging is essentially admitting the test framework isn't helpful. I think expect(a).toXXX(b) will provide better velocity for most engineering teams. I'd rather see a detailed failure message at the end of a 15 minute CI run than an unhelpful one that needs code edits to understand. Especially as the team & codebas…
> The benefit of this style are better error messages. Instead of just “false is not true”, the testing framework can print values for x and y.
> I don’t find this useful. Using the check style testing, there are very few assertions actually written in code. Usually, I start with plain asserts without messages. The first time I debug an actual test failure for a particular function, I spend some time to write a detailed assertion message. To me, fluent assertions are not an attractive point on the curve that includes plain asserts and hand-written, context aware explanations of failures. A notable exception here is pytest approach — this testing framework overrides the standard assert to provide a rich diff without ceremony.