I’ve been toying around with a little side project to learn Svelte. I feel like I’ve been getting a good handle on the basics of the framework and I’ll write more about my impressions in a future post. What I want to talk about here is setting up a unit testing framework.
I initially skipped this step with a plan to add Jest later. I’ve used and liked Jest in the past with React projects and I’m not interested in learning a new testing framework at this time. They seem to be mostly the same, until their not, and the muscle memory starts throwing you off.
There isn’t an official Jest plugin for SvelteKit applications so my journey started with a Google search. (Remember tejusparikh.com is a chatGPT free zone!) After installing Babel, Jest, and other required plugins, I was able to successfully test one of my TS files. However I ran into multiple issues getting svelte-testing-library tests to work. In the process of researching the fixes, I learned what I was doing was less than optimal and I should rethink my approach.
Why Jest is not the best solution for testing in Sveltekit
I decided that learning an additional testing framework is better than a wonky build setup and decided to give Vitest a whirl.
Afterall, it has a nicely named helper function
If it was
emacstest, I might have stuck with Jest a little longer.
Vitest is the native testing framework for Vite. Since I was already down the path of blogs, I started there to try and add it to my project. I’ve found that a lot of official documentation assumes that nothing has been written yet and leave out crucial integration steps. This also turned out to be a mistake as the Svelte Testing Library docs had everything that I needed to start testing.
So the most important takeaway of this post: Skip the blogs, just use the Svelte Testing Library docs to get started.
Once installed I was pleasantly surprised to find that my muscle memory for Jest carried over. Chai matchers and Jest matchers are similar enough and the Vitest team has made their mocking library Jest-like.
The test runner is also really nice. It watches by default and automatically runs the test file under active development. It also keeps the console clean without a lot of extraneous content. I don’t recall having this nice of an experience the last time I used a test watcher.
A few useful Vitest tidbits
When testing Svelte code, extending the matchers is very useful. This can be done with an import.
This gives matches like
I also felt it took a little investigation to get typescript to not complain about calling functions like
Wrapping the mock like the following fixes that:
Overall its been a positive experience and I haven’t experienced the small annoyances that often accompany trying to adopt a new testing approach. The creators seem to have thought a lot about dev experience and worked to incorporate the defacto standards to make adoption easy.
Did you like this content?
Playing around with CSS Variables
Since the last time I looked, CSS added support for variables and it's nice for keeping colors consistent.
The Rise and Fall of a Personal Cargo-Cult
Cargo-cults are common when confronted with the unfamiliar and new. This is not that story. Instead this is a story about forgotten knowledge around a complex interaction.