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!

▲

thecopy 7 months ago | parent | next [-]

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.

	▲	loevborg 7 months ago \| parent [-]
		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.

▲

jitl 7 months ago | parent | prev [-]

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

▲

loevborg 7 months ago | parent [-]

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?

	▲	jitl 7 months ago \| parent [-]
		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.