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.

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