How to Test Nuxt Stores with Jest

This is not Photoshopped

The Quick Answer

If you just want to clone a repo or tinker in a sandbox, I get it.

Github: https://github.com/brandonaaskov/how-to-test-nuxt-stores

CodeSandbox: https://codesandbox.io/s/github/brandonaaskov/how-to-test-nuxt-stores

When you first install Nuxt, you have the option to install a test framework. When you do, it gives you a sample test… of a component. That’s great and all, but in most enterprise web apps you’re going to have the majority of your logic in your stores.

But… where are those examples? It’s almost as if this had never been considered by the nuxt team or community. This plagued me for nearly a year, until pimlie on the Nuxt Discord server helped me understand more about how to access and control what nuxt is building under the hood. Huge props to pimlie.

In short, this is now a solved problem. Let’s get into it.

The Problem

The great thing about nuxt is that it takes care of a lot of tooling for you. This is largely thanks to conventions, like how the pages directory becomes the routing, or how your stores directory becomes a bunch of Vuex modules.

In nuxt, you can get access to the store most commonly from the context object, or by using the helpers that come with Vuex (e.g. mapGetters, mapMethods, mapActions). If your /stores/ folder has more than just an index.js file, then nuxt is building your stores into Vuex modules behind the scenes. It also surfaces that store on the context object for you.

So the problem becomes, how do we rebuild/structure our stores in a way that we can test them in the same way we use it in our pages and components? Do we write all that store building logic ourselves? How can we reuse what nuxt is already doing for us when it builds?

The Solution

There are two key parts here:

1. using a setup file that runs once before Jest starts running any test suites
2. dynamically importing the built store into the test files

We’re going to add a globalSetup reference in our jest.config.js file. I’ve named mine jest.setup.js and it lives right alongside the Jest config file.

Line 2 is the only thing worth noting on this one

The purpose of this setup file is to run once before any tests start running. This gives us a chance to run a nuxt build, which is the critical piece to this whole thing. We tell nuxt to only build the store by overriding all the config elements of what to build. Lastly and very important, we expose the path to that built store’s location as an env var. We’ll later be able to grab that in our tests:

Import nuxt config, override booleans, override other stuff, set spa mode and build

And finally, the test itself. The piece to focus on is the setup: the beforeAll and beforeEach blocks:

In the beforeAll block, we leveraged that env var to dynamically import our built store. In the beforeEach block, we create a fresh store each time to keep our tests clean and independent.

Wrapping Up

I’ve linked to a Github repo and CodeSandbox at the top of the article, and I encourage you to play with it. The sample gists above were pulled from there. If you’re having trouble getting this to work in your codebase, try first bringing your stores and test files into this repo, so you can see it in a known working environment. That way you can isolate any errors that might be due to your test files before bringing them back to your codebase to get Jest configured correctly. Your mileage may vary, every codebase is different.

Good luck!

If you have any improvements you want to make, please submit a PR. I’d love that. And if you do, you should know that I work at Rocket Insights, we’re awesome, and we’re hiring 🤓