Why you should NOT use Jest w/ Solid
Tags: javascript, solidjs, jest, vitest
Published: 2024-03-06 07:18:13

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](https://www.solidjs.com/guides/testing) 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](https://github.com/lukeed/uvu). I didn't consider the latter at all since the maintenance has been [sporadic](https://github.com/lukeed/uvu/graphs/code-frequency) at best since 2020, so Jest was a clear choice. I followed their advice to

```console
npx degit solidjs/templates/ts-jest my-solid-project
```

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:

 ```json
    "@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",
```

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](https://jestjs.io/docs/ecmascript-modules) 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](https://vitest.dev/) 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](https://github.com/solidjs/templates/tree/main/ts-vitest) for this exact setup, but I decided to keep things absolutely simple, and followed Vitest's [installation guide](https://vitest.dev/guide/). This boiled down to installing these dependencies:

```json
   "@solidjs/testing-library": "^0.8.6",
   "jsdom": "^24.0.0",
   "vitest": "^1.3.1"
```
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.