Unit testing with Vue — Approach, tips, and tricks

This post was published in 2017, and some information may now be outdated.

When building a web-app in Vue or any other JS Framework, it’s important to make sure Vue components work as intended throughout the many iterations a project can have. Vue.js allows a very easy and ready to go testing setup with Vue Webpack Template, which already includes a boilerplate for unit tests (using Karma and Mocha) and E2E tests (using Nightwatch). The purpose of this article is to provide different unit test examples on various domains using Karma and Mocha. But first, it’s important to understand some basic JS testing keywords.

[Card Banner][Card Banner][Card Banner]

Component Tests — Using Vue instance

A component has many structures that should be tested:

Lifecycle hooks: For example, test if a function is called when the component is mounted, updated, …
Methods: Test if the function’s return is the expected or if the changes on data were correctly made.
Watchers: When changing a prop or data value, check if the watcher is invoked.
Computed properties: Check if the computed property is returning the intended value.

Components can have multiple functions that use each other as a dependency and this can turn into some complex behaviors. So, it’s important to:

Try to make small, easy to test functions (too many dependencies or complex functions make tests harder to write — and the code harder to read as well).
A function should return a value or change a field on the component’s data in order to be easier to test.
Control your test environment. Focus on testing a single unit of code, mocking the environment or dependencies invocations. Using shallow instead of mount helps to control how the component’s instance renders. When a component is connected to store (either by mapActions, mapState or mapGetters) it’s really important to mock the store and pass it as a global parameter to the component’s instance.

When a component instance is created, a wrapper around the component instance (also named vm) is created and it provides a great API to edit props, data, and many other properties.

Be aware that avoriaz syntax (which is very similar to vue-test-utils syntax) is used in the following tests.

Testing Lifecycle Hooks

A Vue component has multiple lifecycle hooks and to test those, actions that trigger them must be done (create the instance to test beforeMount and mounted while destroying it will trigger the beforeDestroy and destroyed).

Using this component:

&lt; template &gt; &nbsp;&lt; div &gt;  &lt; /div &gt; &lt; template &gt; &lt; script &gt; &nbsp;export default {  &nbsp;&nbsp; // == Lifecycle   &nbsp;&nbsp; mounted () {    &nbsp;&nbsp;&nbsp; window.addEventListener('scroll', this.handleScroll)    &nbsp;&nbsp;},    &nbsp;&nbsp;destroyed () {    &nbsp;&nbsp;&nbsp; window.removeEventListener('scroll', this.handleScroll)   &nbsp;&nbsp;}, &nbsp;&nbsp;// == Methods &nbsp;&nbsp; methods: {   &nbsp;&nbsp;&nbsp; handleScroll () {   &nbsp;&nbsp;&nbsp;&nbsp;   console.log('handleScroll')     &nbsp;&nbsp;&nbsp;&nbsp;   return   &nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;  } &nbsp; } &lt; /script &gt; ‍To check if mounted and destroyed hooks work as intended, an instance of this component should be created and destroyed. Since stub can be applied not only to the component’s instance (and therefore the component’s methods) but also to the window, it’s possible to verify if events are being handled as well.On the test below it’s possible to see how the lifecycle hooks are tested:-- CODE language-js line-numbers -- describe('Basic component', () => { &nbsp; describe('Lifecycle', () => {   &nbsp;&nbsp; it('Mounted', done => {    &nbsp;&nbsp;&nbsp;  const handleScrollStub = sinon.stub(BasicComponent.methods, 'handleScroll')     &nbsp;&nbsp;&nbsp; const addEventStub = sinon.stub(window, 'addEventListener') &nbsp;&nbsp;&nbsp;const wrapper = mount(BasicComponent) &nbsp;&nbsp;&nbsp;expect(addEventStub).to.be.calledWith('scroll', wrapper.vm.handleScroll) &nbsp;&nbsp;&nbsp; handleScrollStub.restore() &nbsp;&nbsp;&nbsp;     addEventStub.restore()    &nbsp;&nbsp;&nbsp;  done()   &nbsp;&nbsp; }) &nbsp;&nbsp; it('Destroyed', done => {     &nbsp;&nbsp;&nbsp; const wrapper = mount(BasicComponent)    &nbsp;&nbsp;&nbsp;  const handleScrollStub = sinon.stub(wrapper.vm, 'handleScroll')     &nbsp;&nbsp;&nbsp; const removeEventStub = sinon.stub(window, 'removeEventListener') &nbsp;&nbsp;&nbsp; wrapper.destroy() &nbsp;&nbsp;&nbsp; expect(removeEventStub).to.be.calledWith('scroll', wrapper.vm.handleScroll)   &nbsp;&nbsp;&nbsp;handleScrollStub.restore()  &nbsp;&nbsp;&nbsp;    removeEventStub.restore()   &nbsp;&nbsp;&nbsp;   done()  &nbsp;&nbsp;  }) &nbsp;  }) }) ‍Creating spies or stubs on the component (BasicComponent — as you see in the Mounted example) instead of creating them on the instance (wrapper.vm) is useful when you want to mock / spy on a dependency that will be invoked on the instance mount lifecycles (like beforeMount or mounted).<h3 id="">Testing Methods</h3>Methods should always have a clear way of being tested, either by returning a value / Promise, changing a component’s data or controlling other functions invocations. Thinking of how a function will be tested will very probably improve the code’s quality and maintainability.Many times functions behavior changes depending on a parameter value or other function’s invocation. The context should be mocked (probably using stubs) to test all use cases.-- CODE language-js line-numbers -- &lt; template &gt; &nbsp; &lt; div &gt; &lt; /div &gt; &lt; /template &gt; &lt; script type="text/javascript" &gt; export default {  &nbsp; ...  &nbsp; data () {   &nbsp; &nbsp;  return {   &nbsp; &nbsp; &nbsp;    currentObjects: [],   &nbsp; &nbsp; &nbsp;    hasError: false   &nbsp; &nbsp;  }  &nbsp; }, &nbsp;  methods: {  &nbsp; &nbsp;   getObjects () {   &nbsp; &nbsp; &nbsp;    ...  &nbsp; &nbsp;   },  &nbsp; &nbsp;   setObjects () {    &nbsp; &nbsp; &nbsp;   const objectsOnStore = this.getObjects()   &nbsp; &nbsp; &nbsp;    if(objectsOnStore) {   &nbsp; &nbsp; &nbsp; &nbsp;      this.currentObjects = objectsOnStore   &nbsp; &nbsp; &nbsp; &nbsp;      return true   &nbsp; &nbsp; &nbsp;    } else {     &nbsp; &nbsp; &nbsp;  &nbsp;   this.hasError = true     &nbsp; &nbsp; &nbsp;  &nbsp;   return false   &nbsp; &nbsp;  &nbsp;   }  &nbsp; &nbsp;   } &nbsp;  } } &lt; /script &gt; ‍In the above scenario, setObjectsfunction will have a behavior depending on getObjects result. In order to test both use cases, the return value of getObjects invocation should be controlled as seen in this test:-- CODE language-js line-numbers -- describe('Objects component', () => {  &nbsp;describe('Methods', () => {   &nbsp;&nbsp; it('getObjects - should return true and set the data.currentObjects if getObjects retrieves an array of objects', done => {     &nbsp;&nbsp;&nbsp; const mockedObjects = [        &nbsp;&nbsp;&nbsp;&nbsp;{ id: 1 },       &nbsp;&nbsp;&nbsp;&nbsp; { id: 2 }      &nbsp;&nbsp;&nbsp;] const wrapper = mount(ObjectsComponent)     &nbsp;&nbsp;&nbsp; const getObjectsStub = sinon.stub(wrapper.vm, 'getObjects').returns(mockedObjects) &nbsp;&nbsp;&nbsp;const result =  wrapper.vm.getObjects() &nbsp;&nbsp;&nbsp;expect(result).to.be.true &nbsp;&nbsp;&nbsp;expect(wrapper.data().currentObjects).to.be.deep.equal(mockedObjects) &nbsp;&nbsp;&nbsp;getObjectsStub.restore()    &nbsp;&nbsp;&nbsp;  done()  &nbsp;&nbsp;  }) &nbsp;&nbsp;it('getObjects - should return false and set the data.hasError to true if getObjects retrieves an empty array', done => {   &nbsp;&nbsp;&nbsp;   const mockedObjects = []     &nbsp;&nbsp;&nbsp; const wrapper = mount(ObjectsComponent)      &nbsp;&nbsp;&nbsp;const getObjectsStub = sinon.stub(wrapper.vm, 'getObjects').returns(mockedObjects)      &nbsp;&nbsp;&nbsp;const result =  wrapper.vm.getObjects()     &nbsp;&nbsp;&nbsp; expect(result).to.be.false     &nbsp;&nbsp;&nbsp; expect(wrapper.data().hasError).to.be.true     &nbsp;&nbsp;&nbsp; getObjectsStub.restore()     &nbsp;&nbsp;&nbsp; done()   &nbsp;&nbsp; }) &nbsp; }) }) ‍When using a function that depends on an API call, an approach to take is to use a Promise. In this scenarios, the best way to proceed is to return the Promise.The following component is connected to store. The store should be completely mocked in order to control the test’s context and avoid any kind of errors.-- CODE language-js line-numbers -- &lt; template &gt; &nbsp; &lt; div &gt; &lt; /div &gt; &lt; /template &gt; &lt; script type="text/javascript" &gt; import { GET_OBJECTS } from 'services/constants/action-types' export default { &nbsp; ...  &nbsp;data () { &nbsp;&nbsp;   return {   &nbsp;&nbsp;&nbsp;   currentObjects: []  &nbsp;&nbsp;  } &nbsp; }, &nbsp; methods: {  &nbsp;&nbsp;  ...mapActions('objects', {   &nbsp;&nbsp;&nbsp;   getObjectsAction: GET_OBJECTS   &nbsp;&nbsp; }),  &nbsp; &nbsp; setObjects () {      &nbsp;&nbsp;&nbsp;return this.getObjectsAction()       &nbsp;&nbsp;&nbsp;&nbsp; .then((response) => {       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;   this.currentObjects = response    &nbsp;&nbsp;&nbsp;&nbsp;    })   &nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;  } &nbsp;} &lt; /script &gt; ‍Returning the Promise allows the API call to be stubbed and this way, it triggers the Promise’s resolve. All the assertions should run on the callback.Considering that getObjectsAction returns a Promise (that will perform the API request on the action), a good way to test this function would be:--CODE language-js line-numbers -- import { GET_OBJECTS } from 'services/constants/action-types' describe('Objects component', () => { &nbsp;  let store  &nbsp;let state  &nbsp;let actions beforeEach(() => {  &nbsp;  actions = {}  &nbsp;  actions[GET_OBJECTS] = sinon.stub() &nbsp;state = {    &nbsp;&nbsp;  modules: {     &nbsp;&nbsp;   // mock state, with actions and getters if any      &nbsp;&nbsp;  objects: {      &nbsp;&nbsp;&nbsp;    namespaced: true,        &nbsp;&nbsp;&nbsp;  state: {        &nbsp;&nbsp;&nbsp;&nbsp;    objs: []        &nbsp;&nbsp;&nbsp;  },        &nbsp;&nbsp;&nbsp;  actions       &nbsp;&nbsp; }     &nbsp; }   &nbsp; } &nbsp;store = new Vuex.Store(state)  }) describe('Methods', () => { &nbsp;   it('getObjects - should set data.currentObjects with response returned from getObjects', done => {     &nbsp;&nbsp; const mockedObjects = [   &nbsp;&nbsp;&nbsp;     { id: 1 },    &nbsp;&nbsp;&nbsp;    { id: 2 }   &nbsp;&nbsp;   ] &nbsp;&nbsp;const wrapper = shallow(ObjectsComponent, { &nbsp;&nbsp;&nbsp;       store  &nbsp;&nbsp;    }) &nbsp;&nbsp;const getObjectsStub = sinon.stub(wrapper.vm, 'getObjects').returns(mockedObjects) &nbsp;&nbsp;wrapper.vm.getObjects() &nbsp;&nbsp;&nbsp;       .then((result) => {  &nbsp;&nbsp;&nbsp;        expect(result).to.be.true   &nbsp;&nbsp;&nbsp;       expect(wrapper.data().currentObjects).to.be.deep.equal(mockedObjects) &nbsp;&nbsp;&nbsp;getObjectsStub.restore()  &nbsp;&nbsp;&nbsp;        done()   &nbsp;&nbsp;     })   &nbsp; }) &nbsp; }) })‍This approach (returning a Promise or a chain of Promises) is very useful in scenarios where requests need to be mocked to avoid timeout errors and allowing to test how a function will perform after the Promise’s resolve. Instead of resolving the Promise, reject it will also trigger the catch scenario on the test. <h3 id="">Testing Watchers</h3>A watcher is used to react to data changes and it can be applied to a component’s props or data. To trigger watchers on the test, <a href="https://vue-test-utils.vuejs.org/en/api/wrapper/setData.html" target="_blank" id="">setData</a> or <a href="https://vue-test-utils.vuejs.org/en/api/wrapper/setProps.html" target="_blank" id="">setProps</a> methods can be used.-- CODE language-js line-numbers -- &lt; template &gt; &nbsp; &lt; div &gt; &lt; /div &gt; &lt; /template &gt; &lt; script type="text/javascript" &gt; export default { &nbsp; props: {  &nbsp;&nbsp;  propId: {  &nbsp;&nbsp;&nbsp;    type: Number,  &nbsp;&nbsp;&nbsp;    required: true  &nbsp;&nbsp;  } &nbsp;  }, &nbsp; methods: {   &nbsp;&nbsp; consoleLogValue(value) {    &nbsp;&nbsp;&nbsp;  console.log(value)   &nbsp;&nbsp; } &nbsp; }, &nbsp;  watch: {   &nbsp;&nbsp; propId (newVal) {   &nbsp;&nbsp;&nbsp;   this.consoleLogValue(newVal)   &nbsp;&nbsp; }  &nbsp;}, } &lt; /script &gt; ‍Changing propId will trigger the watcher.This test will only check if consoleLogValue is being invoked with the correct parameter using calledWith as there is no intention to verify how consoleLogValue behaves. That should be done in another test. For this reason, a stub is applied to consoleLogValue.-- CODE language-js line-numbers -- describe('Watcher component', () => { &nbsp; let props &nbsp; beforeEach(() => {  &nbsp;&nbsp;  props = {    &nbsp;&nbsp;&nbsp;  propId: 1   &nbsp;&nbsp; } &nbsp; }) &nbsp; describe('Watcher', () => {  &nbsp;&nbsp;  it('propId', done => {   &nbsp;&nbsp;&nbsp;   const wrapper = shallow(WatcherComponent, {    &nbsp;&nbsp;&nbsp;&nbsp;    propsData: props    &nbsp;&nbsp;&nbsp;  })    &nbsp;&nbsp;&nbsp;const consoleLogValueStub = sinon.stub(wrapper.vm, 'consoleLogValue') &nbsp;&nbsp;&nbsp;wrapper.setProps({     &nbsp;&nbsp;&nbsp;&nbsp;   propId: 2    &nbsp;&nbsp;&nbsp;&nbsp;  })  &nbsp;&nbsp;&nbsp;expect(consoleLogValueStub).to.be.calledWith(2)  &nbsp;&nbsp;&nbsp;    consoleLogValueStub.restore()  &nbsp;&nbsp;&nbsp;    done() &nbsp;&nbsp;   }) &nbsp; }) }) <h3 id="">Testing computed properties</h3>It’s usual to use computed properties to retrieve a value depending on one or multiple props. Computed properties usually represent simple operations that shouldn’t be placed on the template to be easier to maintain.-- CODE language-js line-numbers -- &lt; template &gt; &nbsp; &lt; div :class="themeDiv" &gt; &lt; /div &gt; &lt; /template &gt; &lt; script type="text/javascript" &gt; export default {  &nbsp;props: {  &nbsp;&nbsp;  plan: {    &nbsp;&nbsp;&nbsp;  required: true,    &nbsp;&nbsp;&nbsp;  type: String   &nbsp;&nbsp; }  &nbsp;},  &nbsp;computed: {   &nbsp;&nbsp; themeDiv: function () {   &nbsp;&nbsp;&nbsp;   if (this.plan === 'pro') {     &nbsp;&nbsp;&nbsp;&nbsp;   return 'blue'     &nbsp;&nbsp;&nbsp; } else if (this.plan === 'trial') {     &nbsp;&nbsp;&nbsp;&nbsp;   return 'soft-blue'     &nbsp;&nbsp;&nbsp; } else {     &nbsp;&nbsp;&nbsp;&nbsp;   return 'orange'   &nbsp;&nbsp;&nbsp;   }   &nbsp;&nbsp; } &nbsp; } } &lt; /script &gt; ‍To access computed properties, we can use the component instance directly (wrapper.vm.computedProperty). That said, setProps can be used to test all the branches:-- CODE language-js line-numbers -- describe('Computed component', () => {  &nbsp;let props &nbsp; beforeEach(() => {  &nbsp;&nbsp;  props = {   &nbsp;&nbsp;&nbsp;   plan: 'pro'  &nbsp;&nbsp;  } &nbsp; }) &nbsp; describe('Computed', () => {   &nbsp;&nbsp; it('themeDiv', done => {   &nbsp;&nbsp;&nbsp;   const wrapper = shallow(ComputedComponent, {    &nbsp;&nbsp;&nbsp;&nbsp;    propsData: props    &nbsp;&nbsp;&nbsp;  })     &nbsp;&nbsp;&nbsp; expect(wrapper.vm.themeDiv).to.equal('blue')     &nbsp;&nbsp;&nbsp; wrapper.setProps({     &nbsp;&nbsp;&nbsp;&nbsp;   theme: 'trial'     &nbsp;&nbsp;&nbsp; })     &nbsp;&nbsp;&nbsp; expect(wrapper.vm.themeDiv).to.equal('soft-blue')      &nbsp;&nbsp;&nbsp;wrapper.setProps({       &nbsp;&nbsp;&nbsp;&nbsp; theme: 'standard'      &nbsp;&nbsp;&nbsp;})     &nbsp;&nbsp;&nbsp; expect(wrapper.vm.themeDiv).to.equal('orange')      &nbsp;&nbsp;&nbsp;done()    &nbsp;&nbsp;}) &nbsp;}) }) <h3 id="">Component Tests — Using the Object</h3>As explained before, Vue components’ attributes are all functions. This mindset will make it easier to approach the tests we only need to know how is the object composed. Other than that we’re just testing a function, a small unit of code that shouldn’t have many dependencies.Considering the following component:-- CODE language-js line-numbers -- &lt; template &gt; &nbsp; &lt; div :class="getClasses" &gt; &nbsp;Another component, another test, random probability &lt; /div &gt; &lt; /template &gt; &lt; script type="text/javascript" &gt; export default {   &nbsp; props: {    &nbsp;&nbsp;  classModifiers: {      &nbsp;&nbsp;&nbsp;  type: Array,     &nbsp;&nbsp;&nbsp;  default: () => ['large']    &nbsp;&nbsp;  }   &nbsp; },    &nbsp;computed: {   &nbsp;&nbsp;   baseProbability () {     &nbsp;&nbsp;&nbsp;   if (this.classModifiers.includes('large')) {      &nbsp;&nbsp;&nbsp;&nbsp;    return .8      &nbsp;&nbsp;&nbsp;  }      &nbsp;&nbsp;&nbsp;  return .5     &nbsp;&nbsp; },      &nbsp;&nbsp;getClasses () {      &nbsp;&nbsp;&nbsp;  return this.classModifiers.map(function (class) {       &nbsp;&nbsp;&nbsp;&nbsp;   return `probability--${modifier}`      &nbsp;&nbsp;&nbsp;  })     &nbsp;&nbsp; }    &nbsp;},   &nbsp; methods: {      &nbsp;&nbsp;calcProbability (probMultiplier) {       &nbsp;&nbsp; &nbsp;return this.baseProbability * probMultiplier    &nbsp; &nbsp; }   &nbsp; }  } &lt; /script &gt; In order to test a function that requires values from props or from component’s data (as the Vue instance will not be created now), a variable must be created with this values and passed to the tested function. On the following tests, this variable will be named ‘context’.-- CODE language-js line-numbers -- // Working with the object here! import Probability from '../probability.vue' describe('Probability component', () => {  &nbsp;describe('Computed ', () => {  &nbsp;&nbsp; &nbsp; it('getClasses', done => {   &nbsp;&nbsp;&nbsp;  &nbsp; const context = {    &nbsp;&nbsp;&nbsp;  &nbsp;  classModifiers: ['medium', 'blue-theme', 'rounded-corners']    &nbsp;&nbsp;&nbsp;  }    &nbsp;&nbsp;  &nbsp;expect(Probability.computed.getClasses.call(context))    &nbsp;&nbsp;&nbsp;  &nbsp;   .to.be.eql(['probability--medium', 'probability--blue-theme', 'probability--rounded-corners'])    &nbsp;&nbsp; &nbsp;&nbsp; done()   &nbsp;&nbsp;&nbsp; })   &nbsp;&nbsp; it('baseProbability - should return 0.8 when "large" is on the classModifiers list', done => {     &nbsp;&nbsp;&nbsp; const context = {     &nbsp;&nbsp;&nbsp;&nbsp;   classModifiers: ['large', 'blue-theme', 'rounded-corners']     &nbsp;&nbsp;&nbsp; }     &nbsp;&nbsp;&nbsp; expect(Probability.computed.baseProbability.call(context)).to.be.eq(.8)     &nbsp;&nbsp;&nbsp; done()   &nbsp;&nbsp; })   &nbsp;&nbsp; it('baseProbability - should return 0.5 when "large" is not on the classModifiers list', done => {    &nbsp;&nbsp;&nbsp;  const context = {     &nbsp;&nbsp;&nbsp;&nbsp;   classModifiers: ['medium', 'blue-theme', 'rounded-corners']    &nbsp;&nbsp;&nbsp;  }    &nbsp;&nbsp;&nbsp;  expect(Probability.computed.baseProbability.call(context)).to.be.eq(.5)    &nbsp;&nbsp;&nbsp;  done()   &nbsp;&nbsp; }) &nbsp; }) &nbsp;  describe('Methods ', () => { &nbsp;&nbsp;   it('calcProbability', done => {   &nbsp;&nbsp;&nbsp;   const context = {   &nbsp;&nbsp;&nbsp;     baseProbability: .5  &nbsp;&nbsp;    }  &nbsp;&nbsp;    expect(Loading.methods.calcProbability.call(context, 100)).to.be.eq(50)   &nbsp;&nbsp;   done()  &nbsp;  })  }) }) ‍Without a Vue instance, invoking functions uses the object’s properties (Object.computed, Object.methods, etc). The ‘context’ variable allows the tested function to still use the expected values from the Vue instance data structure.The lifecycles hooks can also be invoked using the object’s properties. Operations like using functions created on mapActions can be placed on the ‘context’ variable to avoid mocking the store (one of this approach’s major advantages). Using the following component:-- CODE language-js line-numbers -- &lt; template &gt; &nbsp; &lt; div  &gt; &nbsp;Lifecycle using object example &lt; /div &gt; &lt; /template &gt; &lt; script type="text/javascript" &gt; import { mapActions } from 'vuex'  import { actionTypes } from 'services/constants'  export default {   &nbsp;  methods: {     &nbsp; &nbsp;  ...mapActions('app', {     &nbsp; &nbsp; &nbsp;    getInitialConfig: actionTypes.APP_GET_CONFIG     &nbsp; &nbsp;  })   &nbsp;  },   &nbsp;  created () {    &nbsp; &nbsp;   this.getInitialConfig()   &nbsp;  }  } &lt; /script &gt; ‍The getInitialConfig function will be placed inside the ‘context’ variable and therefore, a spy is created to understand if the function is called when the created hook is invoked.-- CODE language-js line-numbers -- import Obj from '../Obj.vue' describe('Obj', () => {  &nbsp; describe('Lifecycle', () => {   &nbsp; &nbsp;  it('created', done => {    &nbsp; &nbsp; &nbsp;   const context = {     &nbsp; &nbsp; &nbsp; &nbsp;    getInitialConfig: () => {}     &nbsp; &nbsp; &nbsp;  }    &nbsp; &nbsp; &nbsp;   const getInitialConfigSpy = sinon.spy(context, 'getInitialConfigSpy')    &nbsp; &nbsp; &nbsp;   Obj.created.call(context)   &nbsp; &nbsp; &nbsp;    expect(getInitialConfigSpy).to.be.calledOnce     &nbsp; &nbsp; &nbsp;  getInitialConfigSpy.restore()   &nbsp; &nbsp; &nbsp;    done()  &nbsp; &nbsp;   }) &nbsp;  }) }) <h3 id="">Conclusion</h3>Unit testing can sometimes be tricky and if you’re starting, it will surely cause some pain. But in the end, it’s worth it.Tests bring great advantages to the project and to the developer’s evolution. The developer’s mindset will change to write better, easier to test and more maintainable code using pure functions, following the Do One Thing (DOT) rule instead of overloading a unit of code with multiple responsibilities and taking better decisions over the structure and scalability of an application.This article focused on showing some examples of how to approach various Vue.js testing domains, more like an easy to remind / understand how to approach a certain scenario and to help you all understand what it’s being done when writing a test. Hope it was helpful!

Component Tests — Using Vue instance

Testing Lifecycle Hooks

Related Insights

Streamline your Product workflow: a guide to Raycast, Perplexity AI, and Arc Browser

Phase 0: What should happen before product development

The role of science in effective communication with clients