Repository navigation
Same test api #32
Description
I have played around with Deno's built in test runner before.
it's pretty nice. but i tend to not use it if i'm also writing test cases that should run in different env.
When i write test cases for both NodeJS and Deno then i tend to simply just use a simple array or an object myself to define all test cases and import all files that i want to test. Then i just use a simple logic function that are very similar to console.assert but it throws instead. then i simply just write a for loop to exec all functions, if the env match Deno then i use Deno.test otherwise it have just been a classic for loop that execute. very simple and fast but lose a lot of shiny features for the cost of being more cross compatible. I'm not such a huge fan of any of the existing test framework that exist out there on npm atm.
now i found out that NodeJS also have a test runner built in
it would be nice if both could play ball and work the same way...
I know this isn't something web related but it would be nice if i could write test cases the same way.
Would even wish for there to be some browserified version of it too.
Bonus point if there where something like node --test --browsers that could launch maybe a headless browser or where i could open up a own browser and navigate to url to hook it in.
- then it would dump everything to the console,
- talk with each other over websocket
- hook it into file changes
- have some good CI/CD that could execute all test cases in a browser and exit with either an error or a success in the terminal
Activity
ljharb commentedon Dec 18, 2022
Given that the ecosystem itself is nowhere close to cohering on a test runner API, or even a common featureset, it doesn't seem prudent to try to standardize something nobody can agree on yet.
guest271314 commentedon Aug 9, 2023
No two (2) JavaScript runtimes I have tested (Node.js, Deno, QuickJS, txiki.js, Bun, et al.) implement I/O the same. So I don't think it's possible to test universal conformance until there is a common I/O.
guest271314 commentedon Aug 9, 2023
More importantly I don't think a given implementer's own tests should be the gospel. Deno code should be tested by Node.js folks. Node.js code should be tested by Deno folks, and so forth. It is far too easy for people to write tests that succeed within their own domain. Somebody else has to test and verify for true scrutiny and vetting of claims, that's how the scientific method works.
GeoffreyBooth commentedon Aug 9, 2023
I think there’s something to be said for the user’s request here. It is annoying to have to write separate tests for Node, for Deno, for browsers, for a library that should run in all of them.
I was going to suggest that someone create a userland library that can sit as an abstraction layer over the Node and Deno test runners, but since there is no “browser test runner” and to cover the browser case a general test runner library would need to be added—why not just use a userland test runner library in the first place? There must be some that can run in a variety of runtimes. What is gained by using the built-in ones? Performance?
sagudev commentedon Feb 11, 2026
WPT has a python script that calls executor (impl for each browser, runs test - html page - in browser and collects result) and their own testharness (how browser reports results; in servo we simply print json to console - stdout). So for this case we would need executor for node and deno that would run respective binary with correct arg and parse the results. (BTW as far as I can tell both deno and node impl console.log), so I think the main thing is covered.