DEV Community

Cover image for Why you should NOT use Jest w/ Solid
Daniel Macák
Daniel Macák

Posted on • Edited on

Why you should NOT use Jest w/ Solid

When I was wondering how to introduce testing to my small Solid app which is not that small anymore, hence the need for tests, and also which testing framework to use, I mostly bumped into Jest. Solid's official guide recommends it too. We use it in bigger projects with NX and are somewhat content with it, so I thought, why not?

Jest

The official guide suggests both Jest and Uvu. I didn't consider the latter at all since the maintenance has been sporadic at best since 2020, so Jest was a clear choice. I followed their advice to

npx degit solidjs/templates/ts-jest my-solid-project
Enter fullscreen mode Exit fullscreen mode

and copy the generated configs into my existing project.

The first thing I noticed was that Babel was used. I have nothing against Babel at all, but I don't like when the way testing code is processed differs from the "production" setup, because it creates room for differences and mistakes. Indeed, they even mention it in the guide that the tests won't be typechecked in this setup, only transpiled.

Secondly, I was shocked by the sheer number of dependencies. See for yourself:

    "@babel/core": "^7.23.7",
    "@babel/preset-env": "^7.23.8",
    "@babel/preset-typescript": "^7.23.3",
    "@solidjs/testing-library": "^0.8.5",
    "@testing-library/jest-dom": "^6.2.0",
    "@types/jest": "^29.5.11",
    "@types/testing-library__jest-dom": "^5.14.9",
    "babel-jest": "^29.7.0",
    "babel-preset-jest": "^29.6.3",
    "babel-preset-solid": "^1.8.9",
    "jest": "^29.7.0",
    "jest-environment-jsdom": "^29.7.0",
    "jsdom": "^23.2.0",
    "solid-jest": "^0.2.0",
    "solid-testing-library": "^0.5.1",
Enter fullscreen mode Exit fullscreen mode

This is bad on so many levels. First of all, having so many dependencies is a recipe for problems when so many moving parts have to stay in sync. Secondly, I wasn't even sure what at least half of them was for! Frankly, it's a mess.

Indeed, I got to appreciate all this very soon because running pnpm test produced SyntaxError: Unexpected token 'export'. To keep this short, I can tell you I tried all the suggestions Jest gives on this topic but nothing worked. Jest claims to have experimental support for ES6 modules, but it's not exactly easy to use it, and it didn't help. And again, this could have been so easy, given my production setup already worked, only if Jest could use it without introducing its own.

After trying to get it work for an hour, I decided to give up on Jest and the official testing guide and try something else.

Vitest

I am sure you knew where this is going. Vitest is a Vite-native test runner, meaning if you already are using Vite, you can use the same pipeline for your production and testing code. Solid's starter template even uses Vite by default, so it fits in naturally.

Solid even has a template for this exact setup, but I decided to keep things absolutely simple, and followed Vitest's installation guide. This boiled down to installing these dependencies:

   "@solidjs/testing-library": "^0.8.6",
   "jsdom": "^24.0.0",
   "vitest": "^1.3.1"
Enter fullscreen mode Exit fullscreen mode

Solid's testing-library for utilities, jsdom to be able to mount components, vitest as the testing engine. And to put cherry on top, I didn't have to change any configuration. Beautiful!

Key takeaways

  • Just use Vitest! Jest did a lot for us in the past years, but it can be a real pain to set up and packs too many dependencies.
  • Vitest should be the preferred testing solution in Solid's docs.

PS. I'll go down to Solid's Discord and suggest the change in the docs.

Top comments (0)