4 ms·

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 va

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.

jitl 4y ago
> 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.
- iudqnolq 4y ago
  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. https://matklad.github.io/2021/05/31/how-to-test.html https://matklad.github.io/2021/05/31/how-to-test.html

jitl 4y ago

> 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.

iudqnolq 4y ago
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. https://matklad.github.io/2021/05/31/how-to-test.html https://matklad.github.io/2021/05/31/how-to-test.html