Remix clone Hacker News

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

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