Hacker News Reader

Comment by bilalq | Hacker News Reader

Jest has been pretty wonderful to work with over the last few years. Like any test framework, however, there are real pain points.

I've recently started experimenting with Vitest on a new webapp using Vite/React. It's API compatible with Jest, but integrates with your existing build tool-chain instead of forcing you to configure a parallel one. So far, there's a lot to like. https://vitest.dev/

The `--ui` flag showing a visualization of the dependency graph of a test is probably my favorite little feature.

View on HN

I've been leading the adoption of vitest at my company. It's not perfect, and there are some bugs but the performance gain is truly incredible. We have about 150 snapshots for various UI components and vitest can crunch through all of them in about 5 seconds, whereas it would take Jest 3-4X that time.

It's also nice if you're running a "vite stack", you don't have to pull in babel and a bunch of other libs just to make Jest work.

Do you feel the snapshot tests are useful? I've mostly had bad experiences with them (mostly noise), so interested in hearing what makes them work for you/others.

I (weirdly) got sold on snapshot tests while developing a tree-sitter grammar. They don’t make it super obvious (and most snapshotting test solutions don’t) that you can “update all”, but the workflow makes more sense to me now that I’ve even generated my test cases from a more intentional suite. The goal is for it to be noise! It’s entirely a regression test, and it should alert you if you changed something without knowing you did. But it’s only valuable if you snapshot test the things you expect to be stable, write specific tests for the changes you intend to make, and compare between them.

Their not that terribly useful. We have already been talking about replacing them with proper unit tests. One thing they are very useful for is being a cheap way of showing non-technical leadership that you have "100% test coverage".

I only have a handful of Jest unit tests, but they each take nearly 30 seconds nowadays and I don't really know why. Maybe because everything is wrapped in a Formik top level tag? Maybe it somehow pulls in and executes all my code multiple times over? There's probably something silly going on there.

Anyway as just the one developer on this project, I don't see the value in writing unit tests for every one of my components. They just work, I'll leave them alone for a few years until someone else builds a new UI.

That’s awesome news. Started looking it integrating jest today but we use vite, so this is a very timely post!

Can you use Vitest without Vite? It looks cool, I'd love to know more.

Yup I've used Vitest without Vite for a personal project. I replaced Jest as I was having a lot of trouble with ESM modules (it might be better now)

Thanks! I'll definitely take a closer look - "better than Jest" is a great place to start, but not if it means boiling an ocean first.

I'm pretty sure you can. Though I haven't tried it myself I did a search if we could integrate it into our Next.js app (Next uses Webpack internally) and found this: https://github.com/elpnt/nextjs-vitest-example

Vitest is great for running unit tests, but for component testing I still think running in a real browser and using visual snapshots & diffs is preferable to dom snapshots & diffs in a fake browser env like node + jsdom.

It's not just the fact that jsdom doesn't fully support all browser APIs, but components are building blocks for a primarily visual medium, so being able to build and debug my component tests visually has been a complete game changer when it comes to productivity.

I think the very reasonable counterpoint to that is browser tests are slow to run, to the point that it's infeasible to run locally at scale. That's why for https://reflame.app, I've been building a testing strategy around using serverless compute to run browser component tests with maximum parallelization for a tight feedback loop that takes ~5s for a cold start and 1~2s thereafter, with dependency analysis to rerun only tests that could have changed to keep cost scaling under control.

Yeah, for sure. I'm still a fan of using Cypress for webapp integration testing.

+1 for vitest & vite -- used both as the foundation when porting over a few custom elements and it's a pleasure working with them. Migrating tests from Jest to vitest required almost no changes.

Reply on news.ycombinator.com