7 ms·

With testing built into core, I’m looking forward to the reduction in complexity and number of external testing frameworks. I generally chose tape/ava in the p

With testing built into core, I’m looking forward to the reduction in complexity and number of external testing frameworks. I generally chose tape/ava in the past and vitest these days, but it’s awesome that now a very simple testing mechanism is available in core

silverwind 4y ago
A shame it's not using `expect` syntax, which recently was also adopted by bun.
- hardwaresofton 4y 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 4y 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 4y ago
  expect(me).to.barf.when(i.see(shit.like(this)));
  - jitl 4y 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 4y 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 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.
  - nailer 4y 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 4y 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 4y 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 4y ago
    Excessive chaining is bad, yes. I would at most use a `.not` to invert, anything more is unnecessary.
afavour 4y ago
Same. Every time I dive into a repo using Jest it infuriates me. So slow. The built in test runner is great.
- xavdid 4y ago
  Funny, I have the same reaction for Mocha and always wish it was Jest instead. I love that jest includes all the batteries to get stuff done.
  - nailer 4y ago
    Swapping between vitest and jest, vitest is much faster. Haven't used Mocha for a few years now.
- rockwotj 4y ago
  Take a look at vitest.dev, it's pretty fast and great (especially for typescript)
  - afavour 4y ago
    To be honest the built-in test runner does everything I want.
- jitl 4y ago
  Jest is slow in part because it fully isolates each test file from every other test file. For small, highly-experienced teams those guardrails don't provide much benefit. For large teams, that isolation is essential to prevent cross-test contamination. Another reason Jest is slow is due to how it's usually configured to build code using Babel or tsc. Like vitest, you can configure Jest to use esbuild which makes it much faster than using Babel or tsc. I am not a big Jest fan, but it seems like the most pragmatic test runner when you have 100+ engineers working on a project.

silverwind 4y ago

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

hardwaresofton 4y 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 4y 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 4y ago
expect(me).to.barf.when(i.see(shit.like(this)));
- jitl 4y 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 4y 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 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.
- nailer 4y 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 4y 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 4y 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 4y ago
  Excessive chaining is bad, yes. I would at most use a `.not` to invert, anything more is unnecessary.

afavour 4y ago

Same. Every time I dive into a repo using Jest it infuriates me. So slow. The built in test runner is great.

xavdid 4y ago
Funny, I have the same reaction for Mocha and always wish it was Jest instead. I love that jest includes all the batteries to get stuff done.
- nailer 4y ago
  Swapping between vitest and jest, vitest is much faster. Haven't used Mocha for a few years now.
rockwotj 4y ago
Take a look at vitest.dev, it's pretty fast and great (especially for typescript)
- afavour 4y ago
  To be honest the built-in test runner does everything I want.
jitl 4y ago
Jest is slow in part because it fully isolates each test file from every other test file. For small, highly-experienced teams those guardrails don't provide much benefit. For large teams, that isolation is essential to prevent cross-test contamination. Another reason Jest is slow is due to how it's usually configured to build code using Babel or tsc. Like vitest, you can configure Jest to use esbuild which makes it much faster than using Babel or tsc. I am not a big Jest fan, but it seems like the most pragmatic test runner when you have 100+ engineers working on a project.