CodeX
Published in

CodeX

CODEX

Test your VueJS + TypeScript application

Photo by Markus Spiske on Unsplash

This tutorial is focused on testing a VueJS app using TypeScript. We will be using Jest (the TypeScript version “ts-jest”).

I will be using an open-source app I developed called LEMU. A quick word about it; it is a graphical application to manage BackstopJS visual regression tests. This app has been created with the Vue CLI with a TypeScript configuration along with Jest as a unit test framework.

But let’s get started. We will cover unit testing an application. Unit testing is covering the smallest unit of your software: a function. A unit test should cover every single case possible. Also, it is advised to start from the part of the code that has fewer dependencies on another part of the code. In the unit test, you should either mock your dependencies or make sure that they are already covered by tests. Otherwise, it may be more complex to track where the error is if one of your tests fails.

Any medium-sized to larger-sized app relies on Vuex to handle the state management. And state management is at the base of your application. So let’s start by testing the Vuex store to make sure any of your Vue components use code that is reliable.

Part 1: Testing your store, the mutations, and the getters

As we said before, Vuex stores are at the base of your application. Testing them will make sure the foundations of your application are working nicely.

At the base of your store are the state and the mutations altering it, so we will start with the mutations. Mutations can be quite simple, yet it could be useful to test them. At first, if you don’t have unit tests or you are not testing enough, it is better to test more than less; it will give confidence that your mutations are working, even the simple ones, and it will give the habit to write tests.

So let’s start by creating the first test file. Here is the structure of the project for the store's part.

Structure of the project

For the unit test, it follows the same structure under the “tests/unit” directory.

Structure of the test directory

Now let’s focus on the file structure. This file contains a “describe” section for the name of the tested entity (our store module here), and inside it a “describe” for each function tested. And then inside an “if” block, for each use case of the given function.

If you take the following code:

Extract of store code

In the test file, it gives:

Extract of test code

Testing a mutation

Now that we have the test file structure, let’s dig into the test; starting with the mutation seen above: “setSnackbarDisplayed”. It is a mutation taking a payload into a parameter to set the state for displaying a snack bar on the UI.

A mutation is quite straightforward to test. It is a function taking the state as the first parameter and the payload as the second parameter.

First of all, import your store. In this example, I used a store named “applicationStore”. Note that this is not the main store but a module injected in the main store.

The “mutations” are a property of the store. Then on its property is the mutation you want to test. The “mutations” property can be undefined, so I use the optional chaining operator. In the case it’s undefined, the test will fail, which is what we want. We will test the mutation mentioned above: “setSnackbarDisplayed”.

Calling the mutation to test

As mentioned earlier a mutation is a function with two parameters, the first one being the state. To create an object representing the state.

The state object used for the test

The second parameter is the payload, but whatever fits your tests. Then finally, write your expectation on the state object, as your mutations mutate the state.

Here is the final result:

A test on a mutation

Testing a getter

Testing a getter is quite similar to the mutations. It is contained in the “getters” property of the store object. Same as the “mutations” property, it can be undefined, so let’s use the optional chaining operator. If it is undefined then the test will fail which is what we want.

A getter function takes four parameters:
- the first one is the “state” (the local one, of the module)
- the second is the “getters” (the local one, of the module)
- the third one being the “rootstate”
- the fourth and final one is the “rootGetters”

Calling a getter in your test

The getter then returns the value so you write your expectation on the result. Here is an example of testing a getter.

Testing a getter

So here are the basics to start testing your application. You can check out next part on how to test the “actions” of a Vuex store.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store