Find the Vue.js 2 version here.

The source code for the test described on this page can be found .

Using global.plugins to test $store.state

In a regular Vue app, we install Vuex using app.use(store), which installs a globally available Vuex store in the app. In a unit test, we can do exactly the same thing. Unlike a regular Vue app, we don’t want to share the same Vuex store across every test - we want a fresh one for each test. Let’s see how we can do that. First, a simple <ComponentWithGetters> component that renders a username in the store’s base state.

We can use createStore to create a new Vuex store. Then we pass the new store in the component’s global.plugins mounting options. A full test looks like this:

import { createStore } from "vuex"
import { mount } from "@vue/test-utils"
import ComponentWithVuex from "../../src/components/ComponentWithVuex.vue"
const store = createStore({
  state() {
    return {
      username: "alice",
      firstName: "Alice",
      lastName: "Doe"
    }
  },
  getters: {
    fullname: (state) => state.firstName + " " + state.lastName
  }
})
describe("ComponentWithVuex", () => {
    const wrapper = mount(ComponentWithVuex, {
      global: {
        plugins: [store]
      }
    })
    expect(wrapper.find(".username").text()).toBe("alice")
  })
})

The tests passes. Creating a new Vuex store every test introduces some boilerplate. The total code required is quite long. If you have a lot of components that use a Vuex store, an alternative is to use the global.mocks mounting option, and simply mock the store.

Using the mocks mounting options, you can mock the global $store object. This means you do not need to use create a new Vuex store. Using this technique, the above test can be rewritten like this:

The second approach uses a mock store. On of the good things about this is all the necessary data is declared inside the test, making it easier to understand, and it is a bit more compact. It is less likely to catch regressions in your Vuex store, though. You could delete your entire Vuex store and this test would still pass - not ideal.

Both techniques are useful, and neither is better or worse than the other.

Testing getters

Using the above techniques, getters are easily tested. First, a component to test:

<template>
  <div class="fullname">
    {{ fullname }}
  </div>
</template>
<script>
export default {
  name: "ComponentWithGetters",
  computed: {
      return this.$store.getters.fullname
    }
  }
}

We want to assert that the component correctly renders the user’s fullname. For this test, we don’t care where the fullname comes from, just that the component renders is correctly.

First, using a real Vuex store, the test looks like this:

The test is very compact - just two lines of code. There is a lot of setup involved, however - we are had to use a Vuex store. Note we are not using the Vuex store our app would be using, we created a minimal one with the basic data needed to supply the fullname getter the component was expecting.

An alternative would be to write the test using the global.mocks mounting option:

it("renders a username using computed mounting options", () => {
  const wrapper = mount(ComponentWithGetters, {
    global: {
      mocks: {
        $store: {
          getters: {
            fullname: "Alice Doe"
          }
        }
      }
    }
  })
  expect(wrapper.find(".fullname").text()).toBe("Alice Doe")
})

Now all the required data is contained in the test. Great! I like this. The test is fully contained, and all the knowledge required to understand what the component should do is contained in the test.

The above techniques all work in conjuction with Vuex’s mapState and mapGetters helpers. We can update ComponentWithGetters to the following:

The tests still pass.

Conclusion

This guide discussed:

• using createStore to create a real Vuex store and install it with global.plugins
• how to test $store.state and getters

Techniques to test the implentation of Vuex getters in isolation can be found in this guide.