Use node:test

[remcohaszing]

This replaces uvu with the node --test command and node:test module.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
mdx	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 10, 2023 3:46pm

[wooorm]

I don’t get the need for the --test flag?

[remcohaszing]

node --test discovers and runs test files. It’s the most elegant way to run them IMO.

[wooorm]

node index.js does too? 😅

I feel like that’s much less “magic”. As it’s similar to how I run all other JS code?

[remcohaszing]

Sure, node index.js can run a single test file.

It matters as soon you have multiple test files (such as @mdx-js/mdx). At this point you need a tool to run all of these test files, which node --test provides. The alternative is to create a script that calls run from node:test, which is essentially what node --test does for you.

I like using node --test for everything, as it provides a single well-known entry point for running tests using the Node.js.

[wooorm]

There’s another alternative: use an index file that imports several files: https://github.com/micromark/micromark/blob/main/test/index.js. No tools needed.

The main reason that I like node:test is that any regular file is a test, nothing is injected into them or so which other test runners do, and any error is a correct error, and no flags are needed to use them

single well-known entry point for running tests using the Node.js.

To me that is solved by the test npm script?

[wooorm]

I also don’t really care to learn another resolution mechanism, to learn that oh wait it doesn’t look for .jsx files (so in those cases they have to be passed explicitly)

[remcohaszing]

The difference is that node --test runs all test files in a separate process. Each test file is isolated. Also state from one file (e.g. a patched library or cwd) doesn’t leak into other test files. This is not the same as importing all test files.

Let’s say we have these files:

// a.js
import { beforeEach, test } from 'node:test'

beforeEach(() => {
  console.log('beforeEach a')
})

test(() => {})

// b.js
import { beforeEach, test } from 'node:test'

beforeEach(() => {
  console.log('beforeEach b')
})

test(() => {})

// index.js
import './test/a.js'
import './test/b.js'

node --test runs beforeEach before each test in the file it’s defined in.

$ node --test   
ℹ beforeEach a
✔ <anonymous> (1.686736ms)
ℹ beforeEach b
✔ <anonymous> (1.722439ms)
ℹ tests 2
ℹ pass 2
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 146.868511

node --test runs beforeEach before each test in all files imported.

$ node index.js 
beforeEach a
beforeEach b
beforeEach a
beforeEach b
✔ <anonymous> (1.814503ms)
✔ <anonymous> (0.353704ms)
ℹ tests 2
ℹ pass 2
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 7.957022

Also the npm test script isn’t always used for running just tests. E.g. within the unified ecosystem it’s used to run testing, formatting, and linting.

I do agree it’s unfortunate node --test doesn’t support custom file extensions.

[wooorm]

Well that’s kinda my point, I don’t want stuff like that, that behaves differently when run one way or another 🥲 Again, I like just regular files, that don’t interfere, and if weird process.cwd hacks are needed that they clean up themselves. That can be run fine with Node normally.

And I don’t want to an API with a giant surface. I want to throw errors if stuff is wrong. And in 4 years, when a new test framework is around, we can switch again easily.

Feels very similar to whether to write in .ts or .js files. I am not against types or tests, far from it. But it’s so much easier to maintain things for years if files are just plain javascript files.

within the unified ecosystem it’s used to run testing, formatting, and linting.

test-api and test-coverage do that, then.

You are sometimes going to need to pass other things to Node, with or without --test. So node --test doesn’t always run all the expected tests in the expected way. It sometimes needs to be configured. And that’s what npm scripts solve.

[ChristianMurphy]

The difference is that node --test runs all test files in a separate process. Each test file is isolated. Also state from one file (e.g. a patched library or cwd) doesn’t leak into other test files. This is not the same as importing all test files.

On projects outside unified, I've tended to use the BDD API to handle this (describe blocks with it tests)
Which allows scoping before, after, beforeEach, and afterEach to a single test suite.

[remcohaszing]

Well that’s kinda my point, I don’t want stuff like that, that behaves differently when run one way or another 🥲 Again, I like just regular files, that don’t interfere, and if weird process.cwd hacks are needed that they clean up themselves. That can be run fine with Node normally.

This is exactly what I want. I want test files that don’t interfere with each other, so tests can be run in isolation. I.e. when running npm test and something goes wrong in test/compile.js, I want to be able to run node test/compile.js to troubleshoot the issue. This isn’t possible if it’s run via an import, because other tests might interfere.

I also like using describe to organize somewhat bigger test suites, but that’s not the same as running each test file in a separate process via node --test.

I will change it, because I’d rather move from uvu to node:test than block it over this, but I really think we should leverage node --test.

[ChristianMurphy]

Thanks @remcohaszing!
All for migrating to node:test. 👍
Once CI is passing and @wooorm's comments are addressed this will LGTM.

[wooorm]

TLDR didn’t read everything but LGTM ;)