> 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 & codebase have grown, I've found the detailed failure messages helpful when people ask for assistance – experts are more likely to figure things out on sight, turning tens-of-minutes-to-resolve into seconds-to-resolve.
It's all a tradeoff. Here's one perspective that was influential on now I think about tests.
> 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.
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.