I was shopping for a test runner not long ago. I saw the new Node test runner and experimented with it a bit, but gave it a pass mostly because of its experimental status.
It kind of reminds me of a test runner I once used called tape, which also generates TAP output. My initial reaction when I found tape was, “Brilliant! Yes, let’s use an existing, standardized test output format.” In practice, I found that I didn’t actually care that the test runner was separate from the output formatter. All I cared about was whether the output showed me what I needed when a test failed. In JavaScript, tests are frequently deep equality checks, either in data that can be serialized as JSON or occasionally in presentation components written in a template or markup language. Someone wrote a TAP output formatter to display Jest-like diffs between expected vs. actual deeply nested values, but I wasn’t able to get it to work with tape. Everything past the second or third layer of a given data structure was incorrectly rendered as NULL. I haven’t tried deep equality checks on the Node test runner yet, but that will be the first thing I check if I ever give it another look.
TypeScript support (referred to in this article obliquely as transpilation) is also pretty important. I don’t expect the Node test runner to ever support TypeScript since Node doesn’t have first class TypeScript support anywhere else. Lately I’ve been using ts-jest, but I’m kind of regretting it due to some ambiguity about the correct file extension to use on TS module imports, which is arguably a flaw in TypeScript itself rather than ts-jest. Were it not for that, I would be pretty happy with my choice. When a test written in TypeScript fails, I’m far more confident that the cause is a flaw in the source rather than a typo in the test code.
Is anyone else here writing unit tests in TypeScript? What’s your setup?
Personally I have been using vitest. It is more straightforward to set up than jest, and supports typescript. Unless you need some very specific feature or integration of jest, I would pick vitest over jest in any situation.
Hah. I haven’t had to configure Jest myself until this recent experience trying to use it in a new esm-only project, but as a user it’s always worked perfectly for me in the past. 🤷🏽♀️
We’re using Jest, and it’s pretty terrible. Slow, memory leaks galore, and diffs in test failures appear to be text-based, so it’s often hard to understand which part of the diff is actually meaningful. First time I’ve heard of vitest, might be worth giving it a try on one of our larger projects.
I’m using node:test with node:assert for a project with minimal testing needs. One challenge I ran into was the lack of lifecycle hooks like afterEach, as my tests need to clean up after running (even on failure). Luckily, beforeEach and afterEach just landed in main.
I was shopping for a test runner not long ago. I saw the new Node test runner and experimented with it a bit, but gave it a pass mostly because of its experimental status.
It kind of reminds me of a test runner I once used called tape, which also generates TAP output. My initial reaction when I found tape was, “Brilliant! Yes, let’s use an existing, standardized test output format.” In practice, I found that I didn’t actually care that the test runner was separate from the output formatter. All I cared about was whether the output showed me what I needed when a test failed. In JavaScript, tests are frequently deep equality checks, either in data that can be serialized as JSON or occasionally in presentation components written in a template or markup language. Someone wrote a TAP output formatter to display Jest-like diffs between expected vs. actual deeply nested values, but I wasn’t able to get it to work with tape. Everything past the second or third layer of a given data structure was incorrectly rendered as
NULL
. I haven’t tried deep equality checks on the Node test runner yet, but that will be the first thing I check if I ever give it another look.TypeScript support (referred to in this article obliquely as transpilation) is also pretty important. I don’t expect the Node test runner to ever support TypeScript since Node doesn’t have first class TypeScript support anywhere else. Lately I’ve been using ts-jest, but I’m kind of regretting it due to some ambiguity about the correct file extension to use on TS module imports, which is arguably a flaw in TypeScript itself rather than ts-jest. Were it not for that, I would be pretty happy with my choice. When a test written in TypeScript fails, I’m far more confident that the cause is a flaw in the source rather than a typo in the test code.
Is anyone else here writing unit tests in TypeScript? What’s your setup?
Personally I have been using vitest. It is more straightforward to set up than jest, and supports typescript. Unless you need some very specific feature or integration of jest, I would pick vitest over jest in any situation.
And it supports esm out of the box, which I could not get working with jest at all.
To be honest, in my experience, getting Jest to do anything but the basics like trying to break a rock with your head.
Hah. I haven’t had to configure Jest myself until this recent experience trying to use it in a new esm-only project, but as a user it’s always worked perfectly for me in the past. 🤷🏽♀️
We’re using Jest, and it’s pretty terrible. Slow, memory leaks galore, and diffs in test failures appear to be text-based, so it’s often hard to understand which part of the diff is actually meaningful. First time I’ve heard of vitest, might be worth giving it a try on one of our larger projects.
I’m using
node:test
withnode:assert
for a project with minimal testing needs. One challenge I ran into was the lack of lifecycle hooks likeafterEach
, as my tests need to clean up after running (even on failure). Luckily, beforeEach and afterEach just landed in main.This is what I was taking about :) It just needs some polishing in the rough areas to become a very decent testing solution.