4 ms·

Everyone replaces `assert(isTrue: boolean)` with more specific assertions so that failures can produce helpful and specific error messages; something like asser

by jitl 4y ago

Everyone replaces `assert(isTrue: boolean)` with more specific assertions so that failures can produce helpful and specific error messages; something like assert.isEqual(a, b) can at least print a and b, but ideally can print the difference between a and b (which Jest does) -- where all `assert(a == b)` can produce is "Oops, assertion failed at line XYZ". If you expect `assert(...)` to be magic enough to provide diffing and smart error messages because it's actually some kind of macro... then I guess we have different views on magic. My point about completion is that if you do expect(a).<tab> with a smart library, the library can complete the list of assertions that apply to the type of `a`. Eg, if `a` is an Iterable, a good assertion library could complete `expect(a).toInclude(`. Jest doesn't do type-narrowed assertions (sad) but it could.

iudqnolq 4y ago
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

by jitl 4y ago

iudqnolq 4y ago

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