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

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

▲

neallindsay 8 months ago | parent | prev | 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 8 months 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.

▲

WorldMaker 8 months 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 8 months 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.

	▲	WorldMaker 7 months ago \| parent [-]
		Yeah, if you are writing code specifically for Bun, bun:test is the right tool, and if you are specifically writing code for Node, node:test is the right tool. But if you are writing for the browser the hope is that it shouldn't matter if you test with bun:test or node:test. On Node you will have to "polyfill"/"test mock" a few more browser APIs than with Bun (which tries to follow the browser APIs a bit closer), but those are pretty well known today. I feel like the choice in that case between bun:test and node:test should be whatever is faster/more productive and easier-to-hand, not based on "Bun is more like Safari because it uses JSC" and "Node is more like Chromium because it uses V8". I don't think that difference should matter when choosing a unit test tool. The platform standards should be the standards and the best stuff to unit test shouldn't (in theory) be browser specific and in practice you generally want to be able to "run anywhere". I'd reach to something like Cypress or Playwright for tests that are browser specific and whichever was closest to hand or easiest to use in the moment of bun:test, node:test, or deno:test for the speediest unit test suite. (But also, some of my strong opinions here also include that I'm among those afraid of the Chromium hegemony/monoculture and developers today only testing browser code in a V8 swamp, so yeah "you don't need to test in Bun unless you are worried about Safari testing" concerns me as an implied attitude above.)

▲

jitl 8 months 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 8 months 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 7 months 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.