4 ms·

What's wrong with ordinary expressions? That's discoverable too, and you often don't need any discovery cause it's the same code you write normally. assert(Obj

What's wrong with ordinary expressions? That's discoverable too, and you often don't need any discovery cause it's the same code you write normally. assert(Object.is(foo.bar(), baq)); (where assert is magic that fails woth a friendly message when it's argument is falsy.

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

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