Vitest is fast, jest is faster *

• for the more real world cases

https://vitest.dev/ is claiming to be blazing fast, and that maybe the case for some very unity tests with no dependencies.

But if you're writing real world more feature/integration "unit" tests you're better of sticking with what you have already.

I won't go into much detail, but be aware of the issues before deciding to migrate to vitest

Github issues discussing the problems:

• Vitest runs tests 3x slower than Jest with threads: true
• Coverage is very slow on large projects

I've migrated a large codebase not aware of these issues and now have to wait 10/15 minutes on ci pipeline instead of the 3/4 minutes i used to with jest.

Just be aware of these things before going down the same road i've done.

Comments

[Jiri Spac]

This article is wrong. If you are working on a modern codebase with TS and es modules, it is fastest test runner ATM, see this comment:
github.com/vitest-dev/vitest/issue...

Slowdowns only occur for flow and maybe less files.
For the second problem with coverage, it has been fixed in vitest.

@neophen can you add benchmarks to provide some proof to this "article" of yours?

[Mykolas Mankevicius]

So I'm still getting the issues of slow tests, I don't care much about the "a modern codebase with TS and es modules"

A lot of people are still working on old codebases and migrating to vitest hoping to get speed benefits will get burnt. So will not redact my statement so far.

[Mykolas Mankevicius]

And actually github issue

If you scroll down you still see people have a lot of issues of vitest being 3x slower than jest.

[Mykolas Mankevicius]

It might be wrong by now. I’ll update the article when I have some spare time :)

[TheNotary]

I think this article is still up-to-date. I just came to a project that used vitest instead of CRA to see what it was like to create a react app in a different way. I've just added 3 unit tests that test the <Home /> page produces "Sign in" text somewhere and a few other assertions, but it takes 8 seconds for the test to run. That's a really long time for my computer: Duration 8.60s (transform 626ms, setup 25ms, collect 6.65s, tests 517ms). I'm trying to run tests using the ordinary way, but the configs are all screwed up so we might end up starting over with CRA + typescript if we can't narrow down the problem.

[Joel Sullivan]

Vitest was slower for me, too, initially. However, using this article and the tips on performance in this short note, I was able to accelerate Vitest by ~4x for my 800 tests, making it faster than Jest. All I had to do was add the following to my Vitest config:

    // Speed things up a bit -- these help but probably won't be needed someday
    maxConcurrency: 20,
    pool: 'vmThreads',
    poolOptions: {
      threads: {
        singleThread: true,
      }
    },
    isolate: false, // only safe with the poolOptions above
    css: false,
    deps: {
      optimizer:{
        web: {
          enabled: true,
        }
      }
    },

But who knows, maybe I was overlooking ways to accelerate Jest, too. In any case, I'm very happy with my Vitest performance now, and grateful for this article and the other helpful article I referenced above.
Thank you for sharing your experience!

[Good stuff and well done!]

We have tried pretty much the same config and found it to be even slower than regular threads. Using vmThreads or vmForks kills the performance slowing tests to a crawl on my machine.
The fastest was threads still being over 2.5x slower than Jest.

We have abandoned a migration project after a few days due to that.

YMMV

[Oliver Voutat]

I'm glad to see that I'm not the only one having trouble with vitest.
Lost a lot of time adapting tests to make it work.
It is significantly slower than Jest.
Was not able to adapt all tests yet...
1042 ok vs 25 nok.
Tried to change some configurations to improve duration, but got more tests nok.
With Jest I used to use commonjs for improving speed because we don't really care about type checking in tests, but didn't found an equivalent :

transform: {
'^.+.(j|t)s(|x)$': ['ts-jest', { isolatedModules: true }]
},

Tried many things.
Going nuts over this.
For me is a no go.