Writing unit tests for Svelte (Introduction)

d_ir profile image Daniel Irvine 🏳️‍🌈 Updated on ・3 min read

A couple of months ago, I switched from using React to using Svelte for my side projects. Since I'm a TDDist at heart, I naturally wanted to figure out how to write good unit tests for this new component framework. Turns out not many people are doing that yet so, yep, I went down that rabbit hole. I spent a great deal of time figuring out how to write effective unit tests with Svelte.

I’ve learned enough now so it’s time to share what I learned with you.

But first... here's a question that I hear a lot.

Why should I write unit tests for the front end?

It’s a fairly popular opinion in the front-end community that unit testing is a waste of time, and counter-productive. If people write tests at all, they will be system tests that operate at a high level.

Writing unit tests for components is not straightforward, and for novices it is all too easy to get stuck. Techniques like mocking are hard—really hard-—to get right. On top of that, components are so much about declarative code that it can often seem that unit tests are simply parroting what’s written in the production code.

To the first point, unit testing takes practice to get right. I hope this series puts you on solid footing.

To the second point, I’d agree. Don’t test “static” data. But components are very, very rarely just static data (I’ll come back to this point in the next part of this series.)

The benefits of unit testing on the front-end are the same as on the back-end: assisting you with better design; quickly pinpointing errors; helping you write high-quality code at lightning speed. If you're following TDD [this series is not about TDD] then unit tests also give you a great structure for pairing and mobbing on your work.

Why Svelte?

I became interested in Svelte after watching Rethinking Reactivity and The Return of ‘Write Less, Do More’ by Rich Harris.

The “let’s do things more simply” argument really chimes with me. React is too complicated for my liking, and most React codebases I’ve seen are scrappy without any real structure.

I also buy in to the “lean web” idea, that we should do our bit to save the planet by not deploying large-size libraries like React around by avoiding unnecessary computations when possible. Svelte is a great step in that direction.

Plus, I was ready to try something new.

Now let’s talk about testing...

I’m using Jasmine, but you don’t have to

Because of the whole idea of embracing simplicity and removing bloat, I also decided to step away from Jest and move back to Jasmine. I’ve also tried out the techniques in this series with Mocha, and in this series I’ll provide instructions for both Jasmine and Mocha.

Just like Vim and Emacs, Jasmine is ancient and it works as well as I need it to 😆

Who this guide is for

You do not need to know Svelte to use this guide, but if you don’t I suggest you try at least the first few sections of the Svelte tutorial first—it’s great!

If you know some React, Vue or any other component-based JavaScript framework, you should know enough to get something out of this series.

It’ll also help if you’ve got basic awareness of the standard test functions: describe, it and expect.

The demo repo

You can look at my GitHub repo dirv/svelte-testing-demo for an example of how to put all this together.

GitHub logo dirv / svelte-testing-demo

A demo repository for Svelte testing techniques

In the next part...

That’s it for the introduction. In Part 2, we’ll look at how to set up up a Svelte unit testing environment.

Posted on by:

d_ir profile

Daniel Irvine 🏳️‍🌈


I’m the author of Mastering React Test-Driven Development, available now from Packt. I run the Queer Code London meetup.


Editor guide