Same test api

[jimmywarting]

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

[ljharb]

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]

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]

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.

Now watch. ..., this how science works. One researcher comes up with a result. And that is not the truth. No, no. A scientific emergent truth is not the result of one experiment. What has to happen is somebody else has to verify it. Preferably a competitor. Preferably someone who doesn't want you to be correct.

• Neil deGrasse Tyson, May 3, 2017 at 92nd Street Y

[GeoffreyBooth]

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?