|
| ▲ | neallindsay 17 hours ago | parent | next [-] |
| 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...
https://chromestatus.com/feature/5516876633341952 |
| |
| ▲ | fastball 14 hours ago | parent [-] | | 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. |
|
|
| ▲ | mythz 18 hours ago | parent | prev | next [-] |
| 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 |
|
| ▲ | WorldMaker 18 hours ago | parent | prev [-] |
| 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. |
| |
| ▲ | MrJohz 14 hours ago | parent | next [-] | | 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. | |
| ▲ | jitl 16 hours ago | parent | prev [-] | | 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 16 hours ago | parent [-] | | 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 8 hours ago | parent [-] | | 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. |
|
|
|
