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