undefined | Better HN

0 pointsjitl3y ago0 comments

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.

0 pointsjitl3y ago0 comments

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.

0 comments

3 comments · 1 top-level

iudqnolq3y ago· 2 in thread

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.

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

iudqnolq3y 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

j / k navigate · click thread line to collapse