This articles serves as a guide to unit testing Vue components.
We'll first look at why unit testing is important for creating maintainable software and what you should test. Then, we'll detail how to:
- Create and run a unit test for a Vue component
- Test different aspects of a Vue component
- Use mocks to test asynchronous functions
- Check the code coverage of your unit tests
- Structure your unit test files
If you're interested in learning more about Vue, check out my course: Learn Vue by Building and Deploying a CRUD App.
Dependencies:
- Vue - JavaScript framework
- Vue CLI - Tooling for Vue development
- Jest - JavaScript testing framework
- Node - JavaScript runtime
The source code (along with detailed installation instructions) for the Vue Weather App project that's used in this article can be found on GitLab: Vue Weather App.
Contents
Objectives
By the end of this article, you should be able to:
- Explain why unit testing is important
- Describe what you should (and should not) unit test
- Develop a unit test suite for a Vue component
- Run the unit tests for a Vue project using the Vue CLI
- Utilize the
beforeEach()
andafterEach()
functions within a unit test suite - Write unit tests for testing the implementation details of a Vue component
- Write unit tests for testing the behavioral aspects of a Vue component (click events, etc.)
- Understand how mocking helps to write unit tests
- Write unit tests for mocking a library and testing asynchronous functions
- Check the code coverage of your unit tests
- Develop a well-structured unit test file for testing a Vue component
Why Unit Test?
In general, testing helps ensure that your app will work as expected for your end users.
Software projects with high test coverage are never perfect, but it's a good initial indicator of the quality of the software. Additionally, testable code is generally a sign of a good software architecture, which is why advanced developers take testing into account throughout the entire development lifecycle.
Tests can be considered at three levels:
- Unit
- Integration
- End-to-end
Unit tests test the functionality of an individual unit of code isolated from its dependencies. They are the first line of defense against errors and inconsistencies in your codebase. Unit testing is a fundamental part of the Test-Driven Development (TDD) process.
Unit testing improves the maintainability of your code.
Maintainability refers to making bug fixes or enhancements to your code or to another developer needing to update your code at some point in the future.
Unit testing should be combined with a Continuous Integration (CI) process to ensure that your unit tests are constantly executing, ideally on each commit to your repository. A solid suite of unit tests can be critical to catching defects quickly and early in the development process before your end users come across them in production.
What to Test
What should you test? Or, more importantly: What should you not test?
There are three types of testing to consider with unit testing:
- Implementation details: the underlying business logic that a component uses to produce a result based on a given input
- Public interface/design contract: specific inputs (or props, in this case) produce specific results
- Side effects: "if this, then that"; i.e., when a button is clicked something happens.
Since you can't test all the things, what should you focus on?
Focus on testing inputs and outputs that the end user will interact with. The experience that the users of your product have is paramount!
- Inputs: data, props, user interaction, lifecycle methods, Vuex store, route params, query strings
- Outputs: rendered output, events, data results, Vuex store updates, dispatches
By focusing on testing the inputs/outputs of a software module (i.e., a Vue component), you are testing the key aspects that the end user will experience.
There may be other internal logic in a software module that is complex and needs to be unit tested, but these types of tests are most likely to need updating during a code refactor.
App Overview
Before discussing how to unit test Vue components, I want to give a short overview of the Vue Weather App that we'll be testing.
After cloning down the repo, install the dependencies and add the API key. Once done, the Vue Weather App can be run on your local computer by starting the development server:
$ npm run serve
Review the README for more info on creating and adding the API key from Open Weather.
Once the app is built, you will see a success message similar to:
DONE Compiled successfully in 2750ms 1:34:53 PM
App running at:
- Local: http://localhost:8080/
- Network: http://10.0.0.100:8080/
Note that the development build is not optimized.
To create a production build, run npm run build.
At this point, the development server will be up and running. You can see the Vue app by going to http://localhost:8080 in your favorite web browser. When you first load the app, no data is displayed; you'll just see an input field to enter the city that you'd like to get the weather for:
Without any data entered, both the 'Search' and 'Clear' buttons are disabled.
Once you start entering data for a city (as soon as the first character is added), both the 'Search' and 'Clear' buttons will be enabled:
If you click on 'Search' after entering a valid city, the weather data will be displayed for that city:
At this point, clicking on the 'Clear Weather Data' button will cause the weather data to be cleared:
However, the city that was entered will remain in the input field.
If you click on 'Clear' now, the input field will be cleared and the 'Search' and 'Clear' buttons will become disabled once again:
What happens if you enter an invalid city? What if you click 'Clear' before 'Clear Weather Data'? What other states of the app can you find?
Unit Testing in Vue
Since components are the building blocks of Vue (and really any SPA framework, for that matter), they are the most crucial part of your app as a whole. So, spend the majority of your alloted testing time writing unit tests that test your app's components.
Based on my experience with unit testing Vue components, I've found that the testing tools and framework -- Vue Test Utils and Jest -- satisfy the key aspects of a good test environment:
- tests are easy and fun to write
- tests can be written quickly
- tests can be executed with a single command
- tests run quickly
Hopefully you'll find that unit testing your Vue components is an enjoyable experience, as I think that's key to encouraging more testing.
Unit Testing Tools
There are two tools that we're going to use for unit testing the Vue components:
- Vue Test Utils - the official unit testing utility library for Vue
- Jest - test runner for finding and executing the unit tests
Unit Testing Overview
For starters, let's discuss the naming convention for unit tests in Vue. The unit test file should be of the following format:
<Component Name>
.spec.js
You should typically have one unit test file for each component in your Vue project. Within each unit test file, there can be a single unit test suite or multiple unit test suites.
The unit test files should be placed in a separate location from the Vue components, such as in the "tests/unit" folder:
$ tree -d -L 2
.
├── node_modules
├── public
├── src
│ ├── assets
│ └── components
└── tests
└── unit
Running the Tests
The Vue CLI can be used to run the unit tests using Jest by executing:
$ npm run test:unit > [email protected] test:unit vue-weather-app > vue-cli-service test:unit PASS tests/unit/Footer.spec.js PASS tests/unit/Header.spec.js PASS tests/unit/Banner.spec.js PASS tests/unit/Weather.spec.js PASS tests/unit/Search.spec.js PASS tests/unit/App.spec.js =============================== Coverage summary =============================== Statements : 89.36% ( 42/47 ) Branches : 90% ( 9/10 ) Functions : 94.12% ( 16/17 ) Lines : 89.36% ( 42/47 ) ================================================================================ Test Suites: 6 passed, 6 total Tests: 22 passed, 22 total Snapshots: 0 total Time: 4.255s Ran all test suites.
Examples
Using the the Vue Weather App, let's look at some examples for testing Vue components.
Example 1 - Unit Test Introduction
Let's jump right into an example of a unit test file in Vue! The first unit test file is found in tests/unit/Header.spec.js and it tests the Header
component:
import { shallowMount } from '@vue/test-utils' import Header from '@/components/Header.vue' describe('Header.vue Test', () => { it('renders message when component is created', () => { // render the component const wrapper = shallowMount(Header, { propsData: { title: 'Vue Project' } }) // check the name of the component expect(wrapper.name()).toMatch('Header') // check that the title is rendered expect(wrapper.text()).toMatch('Vue Project') }) })
Mounting
The first line in this file imports a function called shallowMount
from the Vue Test Utils library. The idea of 'mounting' means the loading of an individual component to be able to test it. There are two methods for this in Vue Test Utils:
shallowMount()
- creates awrapper
for the Vue component, but with stubbed child componentsmount()
- creates awrapper
for the Vue component, including mounting any child components
Since our focus is on testing an individual component (the Header
component), we'll use shallowMount()
.
shallowMount()
is better for testing an individual component in isolation, as child components are stubbed out. This is the ideal situation for unit testing.Additionally, using
shallowMount()
for testing a component with a lot of child components can improve the execution time of the unit test as there is no cost (in terms of time) for rendering the child components.
mount()
is useful when you want to include testing the behavior of the child components.
The second line imports the Vue component that is going to be tested, Header.vue.
Describe Blocks
After the import
statements, there is a describe
block which defines a unit test suite.
Within a unit test file, there can be multiple describe
blocks that define different unit test suites. Similarly, each describe
block can contain multiple unit tests, where each unit test is defined by an it
block.
I think about this distinction as:
describe
block - unit test suiteit
block - individual unit test function
What's really nice about unit testing in Vue is that there are a number of built-in encouragements for adding comments. For example, the describe
syntax requires that the first argument be the name of the test suite. When testing Vue components, it's easiest to include the name of the Vue component here.
For each it
block, the first argument is a description of the test function, which should be a short description of what this specific test is doing. In the example above, the it
block tests that the component 'renders message when component is created'.
Expects
As far as the actual unit testing, the first step is to mount the Vue component so that it can be tested:
// render the component const wrapper = shallowMount(Header, { propsData: { title: 'Vue Project' } })
The shallowMount
function returns a wrapper
object, which contains the mounted component and the methods to test that component. The wrapper
object allows us to test all aspects of the HTML generated by the Vue component and all properties (such as data) of the Vue component.
Additionally, the props, passed in to the Header
component, are passed in as the second argument to shallowMount()
.
The actual checks performed in the unit test are:
// check the name of the component expect(wrapper.name()).toMatch('Header') // check that the title is rendered expect(wrapper.text()).toMatch('Vue Project')
These lines perform the following checks on wrapper
to test the Vue component:
- Check if the name of the component is
Header
- Check if the title generated by the component is 'Vue Project'
Both of these checks compare strings, so the recommended test function to use is toMatch()
.
Jest Helpers
While the checks in the unit test file for the Header
component are only checking string values, there are lots of options available from Jest to perform checks:
- Booleans:
toBeTruthy()
- checks that a variable/statement is truetoBeFalsy()
- checks that a variable/statement is false
- Defined:
toBeNull()
- checks if a variable matches only nulltoBeUndefined()
- checks if a variable is not definedtoBeDefined()
- check if a variable is defined
- Numbers:
toBeGreaterThan()
- checks if a number is greater than the value specifiedtoBeGreaterThanOrEqual()
- checks if a number is greater than or equal to the value specifiedtoBeLessThan()
- checks if a number is less than the value specifiedtoBeLessThanOrEqual()
- checks if a number is less than or equal to the value specifiedtoBe()
andtoEqual()
- checks if a number is the same as the value specified (these functions are equivalent for numbers)toBeCloseTo()
- checks if a number is equal to the value specified within a small tolerance (useful for floating-point numbers)
- Strings:
toMatch()
- checks if a string is equal to the value specified (Regex can be used as the value specified!)
- Arrays:
toContain()
- checks if an array contains the specified value
Additionally, the not
qualifier can be used with most of these checks:
expect(wrapper.name()).not.toMatch('Header')
Example 2 - Testing Initial Conditions
This example shows how to test the initial conditions (or state) of the Vue Weather
component.
Here's an outline of the unit test file (defined in tests/unit/Weather.spec.js):
import { shallowMount } from '@vue/test-utils' import Weather from '@/components/Weather.vue' describe('Weather.vue Implementation Test', () => { let wrapper = null // SETUP - run before to each unit test beforeEach(() => { // render the component wrapper = shallowMount(Weather, { propsData: { city: '', weatherSummary: '', weatherDescription: '', currentTemperature: 0.0, lowTemperature: 0.0, highTemperature: 0.0 } }) }) // TEARDOWN - run after to each unit test afterEach(() => { wrapper.destroy() }) it('initializes with correct elements', () => { ... }) it('processes valid props data', () => { ... }) it('emits a custom event when clearWeather() is called', () => { ... }) })
The unit test file for the Weather
component utilizes the shallowMount()
function for rendering the Weather
component, as this component is tested as an individual component in isolation.
BeforEach and AfterEach Blocks
Within the unit test suite (defined within the describe
block), there are two new functions defined:
beforeEach()
- called before the execution of each unit test within this unit test suiteafterEach()
- called after the execution of each unit test within this unit test suite
The beforeEach()
function is used to set a consistent state before running each unit test. This concept is very important to make sure that the order of running the unit tests does not impact the results of the unit tests as a whole.
In this example, the beforeEach()
function renders the component with a default set of prop data:
// SETUP - run before to each unit test beforeEach(() => { // render the component wrapper = shallowMount(Weather, { propsData: { city: '', weatherSummary: '', weatherDescription: '', currentTemperature: 0.0, lowTemperature: 0.0, highTemperature: 0.0 } }) })
The afterEach()
function is used to clean-up any processing performed during the unit test.
In this example, the afterEach()
function destroy
s the wrapper
used during the unit test, so that the wrapper
can be re-initialized for the next unit test in the beforeEach()
:
// TEARDOWN - run after to each unit test afterEach(() => { wrapper.destroy() })
If you want to run code that is executed before or after the overall unit test suite is run, you can use:
beforeAll(() => { /* Runs before all tests */ }) afterAll(() => { /* Runs after all tests */ })
Expects
The first unit test for the Weather
component checks the initial conditions of the Weather
component:
it('initializes with correct elements', () => { // check the name of the component expect(wrapper.name()).toMatch('Weather') // check that the heading text is rendered expect(wrapper.findAll('h2').length).toEqual(2) expect(wrapper.findAll('h2').at(0).text()).toMatch('Weather Summary') expect(wrapper.findAll('h2').at(1).text()).toMatch('Temperatures') // check that 6 fields of data for the temperature are displayed expect(wrapper.findAll('p').length).toEqual(6) expect(wrapper.findAll('p').at(0).text()).toMatch('City:') expect(wrapper.findAll('p').at(1).text()).toMatch('Summary:') expect(wrapper.findAll('p').at(2).text()).toMatch('Details:') expect(wrapper.findAll('p').at(3).text()).toMatch('Current: 0° F') expect(wrapper.findAll('p').at(4).text()).toMatch('High (Today): 0° F') expect(wrapper.findAll('p').at(5).text()).toMatch('Low (Today): 0° F') })
Checks:
- The first expect checks that the name of the component matches the name,
Weather
, that's defined in theWeather
component. - The second section of expects check that the two headers (defined as
h2
elements) are as expected. - The third section of expects check that the six data fields (defined as
p
elements) are as expected.
Example 3 - Testing Props
The second unit test for the Weather
component checks that valid data passed in as prop data is handled correctly by the Weather
component:
it('processes valid props data', () => { // Update the props passed in to the Weather component wrapper.setProps({ city: 'Chicago', weatherSummary: 'Cloudy', weatherDescription: 'Cloudy with a chance of rain', currentTemperature: 45.1, lowTemperature: 42.0, highTemperature: 47.7 }) // check that the prop data is stored as expected within the component expect(wrapper.vm.city).toMatch('Chicago') expect(wrapper.vm.weatherSummary).toMatch('Cloudy') expect(wrapper.vm.weatherDescription).toMatch('Cloudy with a chance of rain') expect(wrapper.vm.currentTemperature).toEqual(45.1) expect(wrapper.vm.lowTemperature).toBeCloseTo(42.0) expect(wrapper.vm.highTemperature).toBe(47.7) // check that 6 fields of data for the temperature are displayed expect(wrapper.findAll('p').length).toEqual(6) expect(wrapper.findAll('p').at(0).text()).toMatch('City: Chicago') expect(wrapper.findAll('p').at(1).text()).toMatch('Summary: Cloudy') expect(wrapper.findAll('p').at(2).text()).toMatch('Details: Cloudy with a chance of rain') expect(wrapper.findAll('p').at(3).text()).toMatch('Current: 45.1° F') expect(wrapper.findAll('p').at(4).text()).toMatch('High (Today): 47.7° F') expect(wrapper.findAll('p').at(5).text()).toMatch('Low (Today): 42° F') })
Since the beforeEach()
function provides a default set of prop data, we need to override the prop data using the setProps()
function.
Checks:
- With the props data updated, we can check that the prop data was properly stored within the
Weather
component by checking the data elements (usingwrapper.vm
). - The second set of expects check that the prop data is used to set the six data fields (defined as
p
elements) are as expected.
Example 4 - Testing User Input (Click Event)
The third unit test for the Weather
component checks that the clear-weather-data
event is emitted by the Weather
component when the user clicks on the 'Clear Weather Data' button:
it('emits a custom event when the Clear Weather Data button is clicked', () => { // trigger an event when the 'Clear Weather Data' button is clicked wrapper.findAll('button').at(0).trigger('click') // check that 1 occurrence of the event has been emitted expect(wrapper.emitted('clear-weather-data')).toBeTruthy() expect(wrapper.emitted('clear-weather-data').length).toBe(1) })
In order to trigger a click event, the button
element must be found in the wrapper
and then the trigger
function is called to trigger the click event.
Once the button is clicked, the unit test checks that only one custom event (with the name of clear-weather-data
) is emitted.
Mocking Examples
Within the App
component, when a user searches for the weather for a city, an HTTP GET call is made to Open Weather to retrieve the data via a third-party library called Axios:
// GET request for user data axios.get('http://api.openweathermap.org/data/2.5/weather?q=' + inputCity + '&units=imperial&APPID=' + this.openweathermapApiKey) .then((response) => { // handle success console.log(response) this.weatherData.city = response.data.name this.weatherData.weatherSummary = response.data.weather[0].main this.weatherData.weatherDescription = response.data.weather[0].description this.weatherData.currentTemperature = response.data.main.temp this.weatherData.lowTemperature = response.data.main.temp_min this.weatherData.highTemperature = response.data.main.temp_max this.validWeatherData = true }) .catch((error) => { // handle error this.messageType = 'Error' this.messageToDisplay = 'ERROR! Unable to retrieve weather data for ' + inputCity + '!' console.log(error.message) this.resetData() }) .finally((response) => { // always executed console.log('HTTP GET Finished!') })
When thinking about how to test making the HTTP GET calls, there are two scenarios that come to mind, each testing the side effect of the actual API call:
- HTTP GET response succeeds (happy path)
- HTTP GET response fails (exception path)
When testing code that utilizes an external API, it's often easier to not actually make the call to begin with by replacing the call with a mock. There are pros and cons to this approach, though.
Pros:
- The tests won't be dependent on a network request
- They won't break if the API goes down
- They will run much faster
Cons:
- You'll need to update the tests whenever the API schema changes
- It's difficult to keep up with API changes in a microservice architecture
- Mocking is a difficult concept to grasp and they can add a lot of clutter to your test suites
At some point you should check the full integration to ensure the shape of the API response hasn't changed.
Since this article is focused on unit testing, we're going to mock the Axios library.
Mocking provides a means to mimic the expected behavior of a software module. Although mocking can be used in production code (very dangerous!), it's typically used during development and testing.
Loading data from an external API takes time. While it typically takes less than one or two seconds to load the data from Open Weather in this app, other external APIs can be more time consuming. Additionally, we want a way to easily check if the HTTP GET request fails. So, we'll add mocks to specify how the GET request would respond.
Example 5 - Testing Asynchronous Code (Successful Case)
The unit tests for the App
component are located in the tests/unit/App.spec.js file.
To get started, we need to import
the Axios library:
import { shallowMount } from '@vue/test-utils' import Content from '@/components/App.vue' import axios from 'axios'
However, we don't want to use the actual Axios library as is done in the source code (App.vue). Instead, we want to create a mock of the Axios library so we don't actually call the external API:
// Mock the axios library jest.mock('axios');
This line tells Jest (the framework responsible for executing our unit tests) that we want to mock the Axios library.
In the unit test file (tests/unit/Content.spec.js), for the Content
component, we're:
- Simulating a successful HTTP GET request
- Simulating a failed HTTP GET request
To start, let's handle the nominal situation where the HTTP GET request is successful.
describe('App.vue Test with Successful HTTP GET', () => { let wrapper = null beforeEach(() => { const responseGet = { data: { name: 'Chicago', weather: [ { main: 'Cloudy', description: 'Cloudy with a chance of rain' } ], main: { temp: 56.3, temp_min: 53.8, temp_max: 58.6 } } } // Set the mock call to GET to return a successful GET response axios.get.mockResolvedValue(responseGet) // render the component wrapper = shallowMount(App) }) afterEach(() => { jest.resetModules() jest.clearAllMocks() }) ... })
BeforeEach and AfterEach Blocks
In the beforeEach()
function, we set the response that should occur when axios.get()
is called. The response is the pre-canned weather data that looks similar to what we get from Open Weather, if we actually made the request. The key line in this section is:
// Set the response from the GET call to axios axios.get.mockResolvedValue(response_get);
This line is the key as it lets Jest know that it should return the response_get
array when axios.get()
is called in the Content
component instead of actually making an HTTP GET call using Axios.
The
mockResolvedValue()
function provided by Jest is actually a shorthand syntax for:
jest.fn().mockImplementation(() => Promise.resolve(value));
The next section of the unit test suite defines the afterEach()
function:
afterEach(() => { jest.resetModules(); jest.clearAllMocks(); });
The afterEach()
function, which is called after each unit test executes, clears any mocks that were created during the unit test execution. This approach is a good practice to clean up any mocks after running a test, so that any subsequent tests start from a known state.
Expects
Now we can define the unit test:
it('does load the weather data when a successful HTTP GET occurs', () => { wrapper.vm.searchCity('Chicago') expect(axios.get).toHaveBeenCalledTimes(1) expect(axios.get).toBeCalledWith(expect.stringMatching(/Chicago/)) wrapper.vm.$nextTick().then(function () { // check that the user data is properly set expect(wrapper.vm.weatherData.city).toMatch('Chicago') expect(wrapper.vm.weatherData.weatherSummary).toMatch('Cloudy') expect(wrapper.vm.weatherData.weatherDescription).toMatch('Cloudy with a chance of rain') expect(wrapper.vm.weatherData.currentTemperature).toEqual(56.3) expect(wrapper.vm.weatherData.lowTemperature).toEqual(53.8) expect(wrapper.vm.weatherData.highTemperature).toEqual(58.6) expect(wrapper.vm.validWeatherData).toBe(true) }) })
Since we already went through the steps of defining the mock and rendering the component (via shallowMount()
), this unit test can focus on performing checks.
The unit test starts by calling the searchCity()
function:
wrapper.vm.searchCity('Chicago')
We check that axios.get()
was called only once and that the HTTP GET call included the correct city name:
expect(axios.get).toHaveBeenCalledTimes(1) expect(axios.get).toBeCalledWith(expect.stringMatching(/Chicago/))
To be very thorough, the weather data also checks for the instance of the App
component rendered in this unit test to make sure it matches the pre-canned data returned from the mock of axios.get()
:
wrapper.vm.$nextTick().then(function () { // check that the user data is properly set expect(wrapper.vm.weatherData.city).toMatch('Chicago') expect(wrapper.vm.weatherData.weatherSummary).toMatch('Cloudy') expect(wrapper.vm.weatherData.weatherDescription).toMatch('Cloudy with a chance of rain') expect(wrapper.vm.weatherData.currentTemperature).toEqual(56.3) expect(wrapper.vm.weatherData.lowTemperature).toEqual(53.8) expect(wrapper.vm.weatherData.highTemperature).toEqual(58.6) expect(wrapper.vm.validWeatherData).toBe(true) })
What is Vue.nextTick()?
The set of checks above are not as straightforward, as they require calling the
nextTick()
function.The unit test framework that we're using for testing the Vue components is Vue Test Utils. This framework makes a simplification to support easier testing by applying DOM updates synchronously.
However, when working with an external API with the Axios library, we're actually dealing with asynchronous behavior (callbacks/promises).
In order to make sure that the DOM is updated after the callback for a successful HTTP GET call, we need to utilize the
nextTick()
function to advance the event loop so that the updates in the 'Success' block of our HTTP POST call are applied to the DOM.If you change the above code to not utilize
nextTick()
, you'll see that these checks will fail.
Example 6 - Testing Asynchronous Code (Failure Case)
While it's nice to test when things go as expected, it's also important to check how our software reacts to negative conditions. With that in mind, let's create a second unit test suite for checking a failed HTTP GET request.
There is no problem with having multiple unit test suites within a single unit test file (.spec.js).
Since the mocks are created in the
beforeEach()
function, there needs to be separate unit test suites with differentbeforeEach()
implementations for both successful and failed HTTP GET responses.
BeforeEach and AfterEach Blocks
The beforeEach()
function in this unit test suite is quite different:
beforeEach(() => { // Set the mock call to GET to return a failed GET request axios.get.mockRejectedValue(new Error('BAD REQUEST')) // Render the component wrapper = shallowMount(App) })
Instead of setting a response to return from the axios.get()
call, we are now returning a failed Promise
object with the response of 'BAD REQUEST'.
The afterEach()
function for this unit test suite is identical to the other unit test suite:
afterEach(() => { jest.resetModules(); jest.clearAllMocks(); });
Expects
Here's the unit test function for testing a failed HTTP GET request:
it('does not load the weather data when a failed HTTP GET occurs', () => { wrapper.vm.searchCity('Chicago') expect(axios.get).toHaveBeenCalledTimes(1) expect(axios.get).toBeCalledWith(expect.stringMatching(/Chicago/)) wrapper.vm.$nextTick().then(function () { // Check that there is no user data loaded when the GET request fails expect(wrapper.vm.weatherData.city).toMatch(/^$/) expect(wrapper.vm.weatherData.weatherSummary).toMatch(/^$/) expect(wrapper.vm.weatherData.weatherDescription).toMatch(/^$/) expect(wrapper.vm.weatherData.currentTemperature).toEqual(0) expect(wrapper.vm.weatherData.lowTemperature).toEqual(0) expect(wrapper.vm.weatherData.highTemperature).toEqual(0) expect(wrapper.vm.validWeatherData).toBe(false) // check that the banner message indicates failure expect(wrapper.vm.messageToDisplay).toMatch('ERROR! Unable to retrieve weather data for Chicago!') expect(wrapper.vm.messageType).toMatch('Error') expect(global.console.log).toHaveBeenCalledWith('BAD REQUEST'); }) })
Just like in the previous unit test suite, we check that only one instance of axios.get()
is called and then there is a check that no weather data was loaded into the App
component.
Code Coverage
When developing unit tests, it can be nice to get an understanding of how much of the source code is actually tested. This concept is known as code coverage.
I need to be very clear that having a set of unit tests that covers 100% of the source code is by no means an indicator that the code is properly tested.
This metric means that there are a lot of unit tests and a lot of effort has been put into developing the unit tests. The quality of the unit tests still needs to be checked by code inspection.
The other extreme where this is a minimal set (or none!) of unit tests is a very bad indicator.
The configuration of Jest (the unit test runner) can be found in jest.config.js.
Depending on how you configured your Vue app when it was initially created, the Jest configuration can either be in jest.config.js ('In dedicated config files' was the selected configuration option) or in package.json ('In package.json' was the selected configuration option).
In order to config Jest to generate the code coverage of our unit tests, we need to append the following configuration items to this file:
collectCoverage: true, collectCoverageFrom: [ "src/**/*.{js,vue}", "!**/node_modules/**" ], coverageReporters: [ "html", "text-summary" ]
These configuration items tell Jest that we want code coverage generated (collectCoverage
), where to generate the coverage data from (collectCoverageFrom
), and how to report the output (coverageReporters
).
With this additional configuration of Jest, let's re-run the unit tests in the Vue CLI:
$ npm run test:unit > [email protected] test:unit vue-weather-app > vue-cli-service test:unit PASS tests/unit/App.spec.js PASS tests/unit/Search.spec.js PASS tests/unit/Weather.spec.js PASS tests/unit/Banner.spec.js PASS tests/unit/Header.spec.js PASS tests/unit/Footer.spec.js =============================== Coverage summary =============================== Statements : 89.36% ( 42/47 ) Branches : 90% ( 9/10 ) Functions : 93.75% ( 15/16 ) Lines : 89.36% ( 42/47 ) ================================================================================ Test Suites: 6 passed, 6 total Tests: 19 passed, 19 total Snapshots: 0 total Time: 6.077s Ran all test suites.
Unit Test Structure
After going through a number of different unit test files, I recommend the following structure for the unit test file for a Vue component:
import { shallowMount } from '@vue/test-utils' import App from '@/App.vue' // Import Vue component to test import axios from 'axios' // Import libraries to mock // Mock the axios library - Only needed if mocking a library jest.mock('axios.') describe('Tests for the ... Component', () => { let wrapper = null beforeEach(() => { // set any initial data and create the mocks of libraries // render the component wrapper = shallowMount(App) }) afterEach(() => { jest.resetModules() jest.clearAllMocks() // Only needed if mocking a library }) it('check the initial conditions when the component is rendered', () => { // check the name of the component expect(wrapper.name()).toMatch('...') }) it('check successful events', () => { }) ... })
Key items:
- Each unit test suite has a related set of unit tests
- Utilize the
beforeEach()
andafterEach()
functions to create independent unit test functions - Create mocks of any libraries used within the Vue component that's tested
- Render the components in the
beforeEach()
function and update prop data within the unit test functions - Utilize
shallowMount()
overmount()
to focus on testing individual components
Conclusion
This article provides a guide for unit testing Vue components, focusing on:
- Why you should write unit tests
- What you should (and should not) unit test
- How to write unit tests
Put simply, when considering what to test, focus on testing the inputs and outputs (actual results), not the underlying business logic (how the results are produced). With this in mind, take a minute or two to review the examples again, taking note of the inputs and outputs tested.
Again, if you're interested in learning more about Vue, check out my course: Learn Vue by Building and Deploying a CRUD App.