5 ms·

A shame it's not using `expect` syntax, which recently was also adopted by bun.

hardwaresofton 3y ago
Well I'm sure they knew about it -- maybe there's an impassioned debate on a GH Issue/Discussion somewhere on why they left it out. The refactoring of expect to a reusable library (that hopefully everyone could depend on) would be awesome as well. AFAIK there are multiple expect() implementations out there right now, would be nice if there was one.
- silverwind 3y ago
  Yes, a standardized expect would be nice, but care has to be taken to not bloat it. Currently I use vitest and https://github.com/jest-community/jest-extended https://github.com/jest-community/jest-extended which gets you a reasonable amount of usable matchers.
bitwize 3y ago
expect(me).to.barf.when(i.see(shit.like(this)));
- jitl 3y ago
  It’s great for tab completion and can be very smart about types, and newer ones like jest don’t have excessive chaining style. Less bad than it used to be
  - iudqnolq 3y ago
    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 3y 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 3y 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 3y 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 3y 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
- nailer 3y ago
  As someone who once made things like that, and is now an adult: I was doing this to show people I could do it. I wasn't thinking of the people using my software but rather myself.
  - bitwize 3y ago
    It's what I call a stupid language trick. Don't get me wrong, they can be fun, and I don't hold things like this against you. But when people want me to write production code like that I want to clock somebody with my keyboard. TDD and BDD types get hot and bothered for this sort of thing since it makes the code look like Gherkin or whatever contrived specification language they favor this month.
    - everforward 3y ago
      I dislike them because it falls into an uncanny valley that messes with my mind. It's close enough to English that my brain tries to context switch from coding to writing English, but it's not close enough for that to actually work. It feels like I end up fighting my own mind. I'm glad somebody has tried it so we know what it looks like, but personally I prefer the more "traditional" syntax.
- silverwind 3y ago
  Excessive chaining is bad, yes. I would at most use a `.not` to invert, anything more is unnecessary.

Well I'm sure they knew about it -- maybe there's an impassioned debate on a GH Issue/Discussion somewhere on why they left it out. The refactoring of expect to a reusable library (that hopefully everyone could depend on) would be awesome as well. AFAIK there are multiple expect() implementations out there right now, would be nice if there was one.

silverwind 3y ago
Yes, a standardized expect would be nice, but care has to be taken to not bloat it. Currently I use vitest and https://github.com/jest-community/jest-extended https://github.com/jest-community/jest-extended which gets you a reasonable amount of usable matchers.

bitwize 3y ago

expect(me).to.barf.when(i.see(shit.like(this)));

jitl 3y ago
It’s great for tab completion and can be very smart about types, and newer ones like jest don’t have excessive chaining style. Less bad than it used to be
- iudqnolq 3y ago
  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 3y 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 3y 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 3y 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 3y 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
nailer 3y ago
As someone who once made things like that, and is now an adult: I was doing this to show people I could do it. I wasn't thinking of the people using my software but rather myself.
- bitwize 3y ago
  It's what I call a stupid language trick. Don't get me wrong, they can be fun, and I don't hold things like this against you. But when people want me to write production code like that I want to clock somebody with my keyboard. TDD and BDD types get hot and bothered for this sort of thing since it makes the code look like Gherkin or whatever contrived specification language they favor this month.
  - everforward 3y ago
    I dislike them because it falls into an uncanny valley that messes with my mind. It's close enough to English that my brain tries to context switch from coding to writing English, but it's not close enough for that to actually work. It feels like I end up fighting my own mind. I'm glad somebody has tried it so we know what it looks like, but personally I prefer the more "traditional" syntax.
silverwind 3y ago
Excessive chaining is bad, yes. I would at most use a `.not` to invert, anything more is unnecessary.