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:testwithnode:assertfor 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.