Hacker News Reader

Comment by thecopy | Hacker News Reader

Im interested if anyone has experience using node's native test runner in a non-trivial project?

We are not using the module mocks from Jest in our project and a quick PoC showed significant (3x) speed improvement, but i am worried about the battle-tested:ness.

View on HN

I just started to use nodejs test runner in a new project. All configuration is basically:

node --experimental-transform-types --experimental-test-module-mocks --env-file test/test.env --test

It then automatically runs all my test/*.tests.ts files.

So nice to get rid of all that extra config. As this is still a tiny project, I can tolerate some API changes in these experimental features.

I've been very happy with node:test (and deno:test), but also I migrated from mostly mocha as jest I found difficult to configure, especially without unnecessary bundling configurations as the ESM support among other things was broken for far too long (but mocha delivered it well). Most of my successful uses of jest were out-of-the-box configs in create-react-app and the Angular tools to strip uses of karma and replace them with jest. (Side rant: Seriously whoever thought that karma was a good idea for a test runner? "I love V8 so much I'm using Node's V8 to spin up another headless Chromium's V8 so I can V8 from inside V8." lolsob)

My experience using built in node:test and other rapidly evolving things is frustration around getting improvements. I test one of my projects with the oldest supported NodeJS version, and simply can’t use node:test there because the old node:test in Node 18 is missing a lot of features. It’s similar to building for Apple’s platforms - great stuff happens every new major version, but there’s no way to use new libraries with older OS versions. Gotta wait for all your users (and yourself) to update your whole runtime to get those new features.

Maybe if you are on Node 23 and you absolutely have everything you need, then node:test is okay, but I DO NOT recommend it.

Yes we're using the built-in test runner and it's much better than jest.

Jest is full of unneeded magic (= complexity), whereas node:test is straightforward and has a better design. Highly recommended. You can turn off process isolation for extra speedup!

How large is your project?

Without process isolation we got 6x speedup vs. jest! But it is difficult to ensure a clean slate between our test suites (~40 suites which all use a test DB)

We are also using some helpers to mock, e.g https://github.com/marchaos/jest-mock-extended - its such helper libraries im concerned about.

A young project and a small team (3 months, 3 developers).

We're working with a relational db, and we're DELETE FROM all tables that we use at the beginning of each test. That's fast enough so far. Process isolation doesn't help you with state in out-of-process dependencies anyway.

Process isolation is an absolute non-negotiable must for any seriously sized project (>50 developers) I’ve worked on

If you start the project with good hygiene and clear guidelines (no mutable global state), it's 100% doable.

AFAIK JUnit and other test runners don't do any process isolation for unit tests. Why is JavaScript so different?

Many major 3rd party libraries in Javascript either have their own global state, like React, or you interact with platform global state, like NodeJS `process` global (eg `process.on(signal, handler)`) or browser `window.navigator` or `window.document` globals. I have also heard plenty of horror stories about Java unit testing pain and suffering from developer tools engineers supporting Java, after all that's why Bazel is so focused on "hermetic" everything.

If I could just make some rules that all engineers would follow exactly, I'd simply make a rule "write no bugs" and then I wouldn't need a test framework at all.

Reply on news.ycombinator.com