4 ms·

I prefer using bun:test [1] where possible, super fast to run, all built-in no need to install any packages, supports watch mode, also TypeScript tests just wor

by mythz 2y ago

I prefer using bun:test [1] where possible, super fast to run, all built-in no need to install any packages, supports watch mode, also TypeScript tests just works out of the box without additional deps or steps. You'll also get all the benefits of bun which is a breath of fresh air over npm. [1] https://bun.sh/docs/cli/test https://bun.sh/docs/cli/test

loevborg 2y ago
Yes, same with node:test https://nodejs.org/api/test.html https://nodejs.org/api/test.html It's an excellent test runner and much, much faster than the others, especially if you set the "isolation" flag to "none".
fastball 2y ago
Testing with Bun would only make sense if you're running it with Bun (or targeting Safari), right?
- mythz 2y ago
  It's my preferred js runtime for developing/testing *any* new TypeScript/JS libs since I prefer writing JS libraries with TypeScript and Bun had the best UX for running TS out of the box (also big fan of their built-in SQLite and $ shell support). It only doesn't make sense if you're testing a library requiring node, otherwise it's my preferred choice for testing my js libs. Even when testing libraries requiring node in which case I'll run the tests with node:test but still use bun's built-in bundler [1] to build & bundle the typescript code base. Basically Bun's my first choice, but will still use node if I have to. [1] https://bun.sh/docs/bundler https://bun.sh/docs/bundler
- WorldMaker 2y ago
  If your JS tests are dependent on specifics in JavaScriptCore or V8 are you really writing unit tests? If you want the extra confidence, run it with bun:test and node:test to cover JSC and V8. But JS should be JS and for unit tests feeling a need to test on multiple JS engines is a possible code smell.
  - jitl 2y ago
    Tests are about catching bugs, not playing no-true-Scotsman about what is or is not “unit test-y enough” to be a valid test.
    - WorldMaker 2y ago
      If you have a bug that acts different on JSC than V8 or vice versa that's not necessarily a bug in your code. It maybe implies that your code is doing something wrong and should take a more web platform "standard" approach. It generally implies that you are relying on browser specifics that you'd likely be better off testing directly in those browsers in functional/integration tests. The point about saying "those aren't unit tests" is that it is a "wrong tool for the wrong job" problem. Of course I don't expect Node or Bun to act like any specific browser. The things I want to test in Node or Bun are "universals" that should work in any JS environment, no matter what. If I need to catch V8-specific bugs or JSC-specific bugs, I want to use a smarter integration testing tool like Cypress or Playwright for that, not slow down my unit test suite trying to make a unit test harness pretend to be browsers.
      - jitl 2y ago
        I misinterpreted what you mean –– I thought what you meant was "even if your software runs in NodeJS, you can test in Bun, and mock out all the Node modules since otherwise it's not a unit test". Agree that for testing code intended to run in a browser, either of Node or Bun is fine.
  - MrJohz 2y ago
    Neither of the test libraries are specific to unit tests, so I don't quite understand that comment. That said, there are a lot more issues than just the differences between JSC and V8 - the Bun and NodeJS runtimes, while theoretically exposing the same modules, have a lot of practical differences that are visible in userland code, such as different exceptions, different orderings of queue events, etc. I imagine quite a lot of more complex code depends in some way on platform behaviours like these.
- neallindsay 2y ago
  The JavaScript language is extremely standardized—the differences between Safari, Chrome, and Firefox are almost 100% down to browser APIs like Bluetooth and MIDI support and such. Those things don't come up in the JavaScript engine. The only exception I can think of is proper tail calls, which Google explicitly removed and I don't know if Mozilla ever tried to implement: https://compat-table.github.io/compat-table/es6/#test-proper_tail_calls_(tail_call_optimisation) https://compat-table.github.io/compat-table/es6/#test-proper... https://chromestatus.com/feature/5516876633341952 https://chromestatus.com/feature/5516876633341952
  - fastball 2y ago
    There is a language spec, but the browsers implement that standard at different rates. I know up until recently negative look-behind didn't work in Safari but did work in Chrome, and RegEx is clearly a language feature rather than an API.

by mythz 2y ago

loevborg 2y ago

Yes, same with node:test https://nodejs.org/api/test.html https://nodejs.org/api/test.html It's an excellent test runner and much, much faster than the others, especially if you set the "isolation" flag to "none".

fastball 2y ago

Testing with Bun would only make sense if you're running it with Bun (or targeting Safari), right?

mythz 2y ago
It's my preferred js runtime for developing/testing *any* new TypeScript/JS libs since I prefer writing JS libraries with TypeScript and Bun had the best UX for running TS out of the box (also big fan of their built-in SQLite and $ shell support). It only doesn't make sense if you're testing a library requiring node, otherwise it's my preferred choice for testing my js libs. Even when testing libraries requiring node in which case I'll run the tests with node:test but still use bun's built-in bundler [1] to build & bundle the typescript code base. Basically Bun's my first choice, but will still use node if I have to. [1] https://bun.sh/docs/bundler https://bun.sh/docs/bundler
WorldMaker 2y ago
If your JS tests are dependent on specifics in JavaScriptCore or V8 are you really writing unit tests? If you want the extra confidence, run it with bun:test and node:test to cover JSC and V8. But JS should be JS and for unit tests feeling a need to test on multiple JS engines is a possible code smell.
- jitl 2y ago
  Tests are about catching bugs, not playing no-true-Scotsman about what is or is not “unit test-y enough” to be a valid test.
  - WorldMaker 2y ago
    If you have a bug that acts different on JSC than V8 or vice versa that's not necessarily a bug in your code. It maybe implies that your code is doing something wrong and should take a more web platform "standard" approach. It generally implies that you are relying on browser specifics that you'd likely be better off testing directly in those browsers in functional/integration tests. The point about saying "those aren't unit tests" is that it is a "wrong tool for the wrong job" problem. Of course I don't expect Node or Bun to act like any specific browser. The things I want to test in Node or Bun are "universals" that should work in any JS environment, no matter what. If I need to catch V8-specific bugs or JSC-specific bugs, I want to use a smarter integration testing tool like Cypress or Playwright for that, not slow down my unit test suite trying to make a unit test harness pretend to be browsers.
    - jitl 2y ago
      I misinterpreted what you mean –– I thought what you meant was "even if your software runs in NodeJS, you can test in Bun, and mock out all the Node modules since otherwise it's not a unit test". Agree that for testing code intended to run in a browser, either of Node or Bun is fine.
- MrJohz 2y ago
  Neither of the test libraries are specific to unit tests, so I don't quite understand that comment. That said, there are a lot more issues than just the differences between JSC and V8 - the Bun and NodeJS runtimes, while theoretically exposing the same modules, have a lot of practical differences that are visible in userland code, such as different exceptions, different orderings of queue events, etc. I imagine quite a lot of more complex code depends in some way on platform behaviours like these.
neallindsay 2y ago
The JavaScript language is extremely standardized—the differences between Safari, Chrome, and Firefox are almost 100% down to browser APIs like Bluetooth and MIDI support and such. Those things don't come up in the JavaScript engine. The only exception I can think of is proper tail calls, which Google explicitly removed and I don't know if Mozilla ever tried to implement: https://compat-table.github.io/compat-table/es6/#test-proper_tail_calls_(tail_call_optimisation) https://compat-table.github.io/compat-table/es6/#test-proper... https://chromestatus.com/feature/5516876633341952 https://chromestatus.com/feature/5516876633341952
- fastball 2y ago
  There is a language spec, but the browsers implement that standard at different rates. I know up until recently negative look-behind didn't work in Safari but did work in Chrome, and RegEx is clearly a language feature rather than an API.