DEV Community: Jur de Vries

Jest unit tests location in vue

Jur de Vries — Wed, 07 Oct 2020 11:32:09 +0000

I like doing test driven development in vue and jest. After doing this for a while I noticed that I don't like the fact that the unit tests live in their own directory apart from the implementation files: I always need some time to find them if I want to work on a component. Why not place the test files next to the component and javascript files as shown in the following directory listing?

- components
    - HelloWorld.spec.js
    - HelloWorld.vue
    - Home.spec.js 
    - Home.vue
- utils

As you can see it is very easy to find the test file and there is no confusion between test files and normal files due to the naming convention of tests (*.spec.js).

So how could we achieve this? It is very simple. We need to change the testMatch configuration of jest. When you created your project using the vue-cli and added jest as the unit testing framework, you will have a jest config file in the root of your project:

// jest.config.js
module.exports = {
  preset: '@vue/cli-plugin-unit-jest'
}

The only thing you have to do is to add the proper textMatch entry to this file:

module.exports = {
  preset: '@vue/cli-plugin-unit-jest',
  testMatch: [
    "**/src/**/*.spec.[jt]s?(x)",
  ]
}

When you now run jest, the test files next to the javascript files will be recognized. You will have to move all your tests next to the components, because with the new setting jest will ignore tests in the tests/unit directory.

How to find these settings?

I found out about this setting by examining the jest config documentation. I also had a look in the initial config by running:

npx jest --showConfig

In the output I saw the initial configuration:

 "testMatch": [
    "**/tests/unit/**/*.spec.[jt]s?(x)",
    "**/__tests__/*.[jt]s?(x)"
  ],

I copied this and just rewrote the first pattern in order to match files in the src directory. As I never use the __tests__ directory I simply deleted this line in order to have no confusion where the tests should be placed.

Creating a custom videoconferencing solution using Vue.js and jitsi

Jur de Vries — Tue, 22 Sep 2020 13:18:54 +0000

Now Corona is raging the world, the performing arts have a problem. Theaters are closed down and the need for an online performing platform is growing. Of course, you can use Zoom or another ready-made video conferencing platform, but then you are really tight to an interface you might not like or is not suitable for a performance.

Together with Keez Duyves I have build a proof of concept for using jitsi at PIPS:lab. The difficulties we encountered inspired me to write this blog.

Prerequisites:

Intermediate javascript knowledge
basic Vue knowledge
Vue cli should be installed globally on your computer
npm should be installed on your computer

All the code can be found on the github repository.

Step 0: First Vue app

I will use the Vue cli to create a very basic Vue app from which we can work.
I am not interested in styling right now, so I will only focus on the plain html.

In order to create a Vue app proceed as follows in the terminal:

vue create jitsi-vue

Choose the default options to generate the first Vue app.
Now go to the directory and run:

npm run serve

Now you will see the following default welcome page in the browser:

The code so far can be found here

Step 1: Empty component

Of course, we don't want this, so let's delete the HelloWorld component and change the App.vue file like this:

<template>
    <div id="app">
        <h1>Performance</h1>
    </div>
</template>

<script>
export default {
    name: 'App',
}
</script>

<style>
#app {
    font-family: Avenir, Helvetica, Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
    text-align: center;
    color: #2c3e50;
    margin-top: 60px;
}
</style>

Now we are ready to start with the jitsi integration.

The code so far can be found here

Step 2: Jitsi library and connect

We are going to use the low level jitsi meet api, so we have full control over the look and feel. The downside is that we have to create all the functionality ourselves but that is exactly what we want.

First we need the library, which we will include using npm:

npm install @lyno/lib-jitsi-meet

Include it in the Vue file using an import statement:

import JitsiMeetJS from '@lyno/lib-jitsi-meet';

Let's try to follow the getting started from the jitsi documentation. We will first perform all the steps in the component itself and then refactor if needed. First get things working, than get things right.

So step one should be the initialisation of the library:

JitsiMeetJS.init();

In order to check something actually happened, we can have a look at the console of the browser and check if anything is logged there::

Success! Something definitely happened there. Now we are ready for the next step:

var connection = new JitsiMeetJS.JitsiConnection(null, null, options);

So there is the first problem: what should the options be? For now, we use an empty object (and we change the var into a const in order to adhere to more moderns javascript standards.)

const options = {};
const connection = new JitsiMeetJS.JitsiConnection(null, null, options);

Then the getting started guide informs us that we can add some listeners to the connection. For now we will simply log the arguments by which the listeners are called to the console:

function onConnectionSuccess() {
  console.log("onConnectionSuccess", arguments);
}
function onConnectionFailed() {
  console.log("onConnectionFailed", arguments);
}
function disconnect() {
  console.log("disconnect", arguments);
}

connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_ESTABLISHED, onConnectionSuccess);
connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_FAILED, onConnectionFailed);
connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED, disconnect);

When we run this in the browser we get an error in the console:

Uncaught ReferenceError: $ is not defined

That's an unexpected result! There was no mention of dependencies, but apparently we need something of a $ function. First guess of course should be jQuery, so let's add that to our code. First by getting it using npm and then including it in our App.vue file.

npm install jquery

In the App.vue file:

    import $ from 'jquery';
    window.$ = $;

When we reload the 'run serve' again we are one step further and get the following error:

Hmm. What to do? Clearly we need hosts settings. The documentation states (although not in the getting started, at the bottom) we have to provide the following options:

serviceUrl - XMPP service URL. For example 'wss://server.com/xmpp-websocket' for Websocket or '//server.com/http-bind' for BOSH.
bosh - DEPRECATED, use serviceUrl to specify either BOSH or Websocket URL.
hosts - JS Object
- domain
- muc
- anonymousdomain
useStunTurn -
enableLipSync - (optional) boolean property which enables the lipsync feature. Currently works only in Chrome and is disabled by default.

We are going to use the publicly available server located at https://meet.jit.si/ and after some peeking around in other projects it turns out that on every jitsi server there is a publicly available config.js file that includes these options and many more.
For the public server it located at https://meet.jit.si/config.js. Let's download it and include it in our code. In order to do that, create a new folder in the src directory called options and copy the config file into this directory.
The directory structure will look like this now:

In order to import the config in our file we have to transform it to a es6 module by replacing

var config = {

export default {

Also, the structure of the file seems to be old as it has no serviceUrl defined. We add that key to the object by taking the 'websocket' value and assign it to 'serviceUrl':

{
    .....
    serviceUrl: 'wss://meet.jit.si/xmpp-websocket',
    .....
}

Now we can import the config as options and feet it into the connection initializer:

import options from './options/config';

Which is in place of the previous definition of options. The complete App.vue script portion will look something like this:

import JitsiMeetJS from '@lyno/lib-jitsi-meet';
import $ from 'jquery';
window.$ = $;

import options from './options/config';

JitsiMeetJS.init();

const connection = new JitsiMeetJS.JitsiConnection(null, null, options);

function onConnectionSuccess() {
  console.log("onConnectionSuccess", arguments);
}
function onConnectionFailed() {
  console.log("onConnectionFailed", arguments);
}
function disconnect() {
  console.log("disconnect", arguments);
}

connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_ESTABLISHED, onConnectionSuccess);
connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_FAILED, onConnectionFailed);
connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED, disconnect);

connection.connect();

export default {
  name: 'App',
}

Now Vue in the default configuration might throw error messages due to linting problems in the config file. You can than fix the linting problems in the file.
After having fixed the errors and looking into the log, you will still see two errors (although it does a lot more already!) which have to do with CORS:

This seems to be related to the 'externalConnectUrl' and 'bosh' properties. They start without defining the protocol:

'//meet.jit.si/......'

Now on localhost it triggers a redirect because localhost is not secure. This causes a CORS error. If we explicitly ask for https this error goes away:

'https://meet.jit.si/........'

So in the config file you have change all the urls starting with '//' to start with 'https://'.

If you did all this and reload the page, there should be no console errors anymore. You should even see the message 'onConnectionSuccess' somewhere hidden in the many messages the jitsi client sends. In order to clean up the messages a bit, we can set the logLevel using:

JitsiMeetJS.setLogLevel(JitsiMeetJS.logLevels.INFO);

Success! Now we have connected, and we can clearly see it in the console now:

The code so far can be found here

Step 3: Joining a room and creating local tracks

Now we are able to create a connection the next step is to join a room. As the quick start guide states we need to perform the following actions:

room = connection.initJitsiConference("conference1", confOptions);
room.on(JitsiMeetJS.events.conference.TRACK_ADDED, onRemoteTrack);
room.on(JitsiMeetJS.events.codsnference.CONFERENCE_JOINED, onConferenceJoined);

And then:

room.join()

So let's implement it, using console logs for onRemoteTrack and onConferenceJoined.
We only can join a room once the connection has been established, so we need to implement the code in the onConnectionSuccess function. For the options we will add an empty object for now:

function onConnectionSuccess() {
  console.log("onConnectionSuccess", arguments);

  const room = connection.initJitsiConference("my-secret-conference", {});
  room.on(JitsiMeetJS.events.conference.TRACK_ADDED, onRemoteTrack);
  room.on(JitsiMeetJS.events.conference.CONFERENCE_JOINED, onConferenceJoined);
  room.join();
}

Now the last thing we have to do is to create the local tracks:

JitsiMeetJS.createLocalTracks().then(onLocalTracks);

Again we don't exactly know what the callback onLocalTracks should look like, so we will write the arguments to the console. The code to create the tracks will now look like this:

function onLocalTracks() {
  console.log("onLocalTracks", arguments);
}

function onConnectionSuccess() {
  console.log("onConnectionSuccess", arguments);
  const room = connection.initJitsiConference("my-secret-conference", {});
  room.on(JitsiMeetJS.events.conference.TRACK_ADDED, onRemoteTrack);
  room.on(JitsiMeetJS.events.conference.CONFERENCE_JOINED, onConferenceJoined);
  room.join();

  JitsiMeetJS.createLocalTracks().then(onLocalTracks).catch(error => {
        console.error("There was an error creating the local tracks:", error);
      }
  );
}

When we run the code now, we get an error again:

Apparently we need to add some options for the createLocalTrack function to succeed. From peeking around in other code, we at least need the devices option so let's add it:

  JitsiMeetJS.createLocalTracks({
    devices: ['video', 'audio']
  }).then(onLocalTracks).catch(error => {
        console.error("There was an error creating the local tracks:", error);
      }
  );

And if we now reload the page we have success!

It turns out we get the created tracks as an array containing one video and one audio track.

Now we have the tracks we should see ourselves in the public room on the jitsi meet server.
I called the room 'my-secret-conference' so let's go to the room url and join on https://meet.jit.si/my-secret-conference.

Surprise!! Although we have tracks and we have confirmation that we have joined the room, nothing can be seen there :-(

After looking into some other implementation it seems that the local tracks need to be added to the newly created room. So we will create the localTracks once the conference has been joined. If we inline that function we can reach the room variable from within the closure. So the code will be:

function onConnectionSuccess() {
  console.log("onConnectionSuccess", arguments);
  const room = connection.initJitsiConference("my-secret-conference", {});
  room.on(JitsiMeetJS.events.conference.TRACK_ADDED, onRemoteTrack);
  room.on(JitsiMeetJS.events.conference.CONFERENCE_JOINED, () => {
    console.log("onConferenceJoined", arguments);
    JitsiMeetJS.createLocalTracks({
      devices: ['video', 'audio']
    }).then((tracks) => {
      console.log("onLocalTracks", tracks);
      tracks.forEach(track => {
        room.addTrack(track);
      })
    }).catch(error => {
          console.error("There was an error creating the local tracks:", error);
        }
    );
  });
  room.join();
}

We have now successfully joined a room, and we have two tracks. But the javascript is not in the Vue component, and it's plain ugly!. We will refactor the code in the next section.

The code so far can be found here

Step 4: refactoring the rather ugly code

So far we have been trying to get the things working in the simplest way. Now it's time to clean up the code.
First thing we notice is that there is a callback hell going on. Lets cleanup that by using promises.
First the connection code:

function connect() {
  return new Promise(((resolve, reject) => {
    const connection = new JitsiMeetJS.JitsiConnection(null, null, options);
    function onConnectionSuccess() {
      console.log("onConnectionSuccess", arguments);
      const room = connection.initJitsiConference("my-secret-conference", {});
      room.on(JitsiMeetJS.events.conference.TRACK_ADDED, onRemoteTrack);
      room.on(JitsiMeetJS.events.conference.CONFERENCE_JOINED, () => {
        console.log("onConferenceJoined", arguments);
        JitsiMeetJS.createLocalTracks({
          devices: ['video', 'audio']
        }).then((tracks) => {
          console.log("onLocalTracks", tracks);
          tracks.forEach(track => {
            room.addTrack(track);
          })
        }).catch(error => {
              console.error("There was an error creating the local tracks:", error);
            }
        );
      });
      room.join();
      resolve(connection);
    }

    function onConnectionFailed() {
      console.log("onConnectionFailed", arguments);
      reject(arguments);
    }

    function disconnect() {
      console.log("disconnect", arguments);
    }

    connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_ESTABLISHED, onConnectionSuccess);
    connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_FAILED, onConnectionFailed);
    connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED, disconnect);

    connection.connect();
  }))
}

As you can see, all the room creation and joining is done in the connection success. But since we have now have a promise that resolves with a connection, we can extract all the room code out. We also can take out some of the console log statements and inline the eventlisteners using arrow functions.

function createAndJoinRoom(connection) {
  const room = connection.initJitsiConference('my-secret-conference', {});
  room.on(JitsiMeetJS.events.conference.TRACK_ADDED, onRemoteTrack);
  room.on(JitsiMeetJS.events.conference.CONFERENCE_JOINED, () => {
    console.log('onConferenceJoined', arguments);
    JitsiMeetJS.createLocalTracks({
      devices: ['video', 'audio']
    }).then((tracks) => {
      console.log('onLocalTracks', tracks);
      tracks.forEach(track => {
        room.addTrack(track);
      });
    }).catch(error => {
          console.error('There was an error creating the local tracks:', error);
        }
    );
  });
  room.join();
}

function connect() {
  return new Promise(((resolve, reject) => {
    const connection = new JitsiMeetJS.JitsiConnection(null, null, options);

    connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_ESTABLISHED, () => {
      resolve(connection);
    });
    connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_FAILED, () => {
      reject('The connection failed.');
    });
    connection.addEventListener(JitsiMeetJS.events.connection.CONNECTION_DISCONNECTED, () => {
      console.log("Connection disconnected");
    });

    connection.connect();
  }))
}

connect().then(connection => {
  createAndJoinRoom(connection);
}).catch(error => console.error(error));

The connection code improved a lot! It's much more readable now. The room joining code is still a mess though. Here we will also use promises to make the code more readable and understandable. Furthermore, we will extract the localTracks code. That should be optional and live in its own function. The track added listener will be added later as well, so we can remove that listener as well.

function createTracksAndAddToRoom(room) {
  JitsiMeetJS.createLocalTracks({
    devices: ['video', 'audio']
  }).then((tracks) => {
    tracks.forEach(track => {
      room.addTrack(track);
    });
  }).catch(error => {
        console.error('There was an error creating the local tracks:', error);
      }
  );
}

function createAndJoinRoom(connection, roomName) {
  return new Promise((resolve) => {
    const room = connection.initJitsiConference(roomName, {});
    room.on(JitsiMeetJS.events.conference.CONFERENCE_JOINED, () => {
      resolve(room);
    });
    room.join();
  });
}

Now the calling code will look like this:

connect().then(connection => {
  return createAndJoinRoom(connection, 'my-secret-conference');
})
.then(room => createTracksAndAddToRoom(room))
.catch(error => console.error(error));

Now the code looks a lot more readable. The only thing is that we should move it to its own file and export the three functions. The code is also not in the Vue component. In order to fix that we will add the connection code in the mounted hook, so the code of the Vue component looks like this:

import { connect, createAndJoinRoom, createTracksAndAddToRoom } from './utils/jitsiUtils'

export default {
  name: 'App',

  mounted() {
    connect().then(connection => {
      return createAndJoinRoom(connection, 'my-secret-conference');
    })
    .then(room => createTracksAndAddToRoom(room))
    .catch(error => console.error(error));
  }
}

The code so far can be found here

Step 5: Displaying the video and audio

Till now, we don't see anything, so the code is rather useless from an end user experience. We need to display the video and audio, so we can actually have a conference.
For that to happen we need the tracks in our view component first, so let's create listener which will add the tracks to a Vue data object:

export default {
  name: 'App',

  data() {
    return {
      tracks: [],
    }
  },

  methods: {
    addTrack(track) {
      this.tracks.push(track);
    }
  },

  mounted() {
    connect().then(connection => {
      return createAndJoinRoom(connection, 'my-secret-conference');
    })
    .then(room => {
      room.on(JitsiMeetJS.events.conference.TRACK_ADDED, track => this.addTrack(track));
      createTracksAndAddToRoom(room);
    })
    .catch(error => console.error(error));
  }
}

Now we have the tracks in our component we can inspect the data very easily in the Vue inspector:

We have two tracks: the video- and the audio track. We want to separate them because the video track needs a video element and the audio track needs an audio element:

  data() {
    return {
      videoTracks: [],
      audioTracks: []
    }
  },

  methods: {
    addTrack(track) {
      if (track.getType() === 'video') {
        this.videoTracks.push(track);
      } else if (track.getType() === 'audio') {
        this.audioTracks.push(track);
      }
    }
  },

The only thing to do now is to render the tags and once rendered attach the tracks to the elements.

<template>
  <div id="app">
    <h1>Performance</h1>
    <video v-for="track in videoTracks" :key="`track-${track.getId()}`" :ref="track.getId()" autoplay />
    <audio v-for="track in audioTracks" :key="`track-${track.getId()}`" :ref="track.getId()" autoplay />
  </div>
</template>

  methods: {
    addTrack(track) {
      if (track.getType() === 'video') {
        this.videoTracks.push(track);
      } else if (track.getType() === 'audio') {
        this.audioTracks.push(track);
      }
      this.$nextTick().then(() => {
        track.attach(this.$refs[track.getId()][0]);
      })
    }
  },

Notice the attaching of the track in nextTick: we have to wait until the element is in the dom. Also there is something strange with refs in v-for loops. The refs are arrays, so we need the first element in the array to get the real ref.

Success again! We are able to render both the video and audio using the jitsi-meet library.

The code so far can be found here

Step 6: Houston, we have a problem!

Now we seem to have a working solution. We are able to connect to a room and display our own video.
Let's open a second window and check if we really have a connection.

If we do that there is no success. Somehow, though the jitsi-meet library says that we are connected, we clearly aren't! Browsing the jitsi documentation is, as we saw earlier, of no help at all. Peeking again in other code that uses this library teaches us that we need to add the room name to the serviceUrl using a url parameter. We can achieve that by adding the room name as a parameter to the connect function and create a custom options object using the room name:

export function connect(roomName) {
  return new Promise(((resolve, reject) => {
     let optionsWithRoom = { ...options };

     optionsWithRoom.serviceUrl = options.serviceUrl + `?room=${roomName}`;
     const connection = new JitsiMeetJS.JitsiConnection(null, null, optionsWithRoom);

    ...
  }))
}

Another problem might be that the browser wants to see some user activity before creating the tracks.
So lets move the connection code from the mounted hook to the methods, so we can connect on a button press:

  methods: {
    ...
   connect() {
      const roomName = 'my-secret-conference';
      connect(roomName).then(connection => {
         return createAndJoinRoom(connection, roomName);
      })
      .then(room => {
         room.on(JitsiMeetJS.events.conference.TRACK_ADDED, track => this.addTrack(track));
         createTracksAndAddToRoom(room);
      })
      .catch(error => console.error(error));
   }
},

We need a button to be able to connect now, so let's add that in the template:

<template>
  <div id="app">
    <h1>Performance</h1>
    <button @click="connect">Connect</button>
    <video v-for="track in videoTracks" :key="`track-${track.getId()}`" :ref="track.getId()" autoplay />
    <audio v-for="track in audioTracks" :key="`track-${track.getId()}`" :ref="track.getId()" autoplay />
  </div>
</template>

If we test with two windows now, we see that there is really a connection!

The code so far can be found here

Conclusion

I showed the process I used to implement an unknown library. We have a very rudimentary version working but there is still a lot to be done:

Connect and disconnect buttons instead on connecting at enter
Muting or not rendering the audio component for the local audio track
Listening to other events (like track removal!)
Separating the video and audio elements in separate Vue components so the mounting is abstracted away
Add styling
Many, many more things to do

I leave this to you. From now on you can use the jitsi documentation and your Vue knowledge to create the rest.

Update January 23, 2021

I added step 6 as without it the code didn't seem to work. I also updated the version of the library in the code that is on github.

Vue TDD by example episode 3: extract components

Jur de Vries — Mon, 31 Aug 2020 15:57:58 +0000

In the previous episode we added the vuex store to the todo component.
In this episode we are going to finish the refactoring by extracting the form and display components.

We will start where the previous tutorial ended. If you didn't follow the previous episodes, I advise you to do that.

You can find the code to start with on github.

Step 1: extract the 'add todo' form

When extracting a component it is tempting to just copy all the code we have into the new component and then writing/copying the tests afterwards.
This approach can lead to testing implementation however, and it is certainly not test driven. For the specific refactorings we are doing in this episode we also need to test the interaction of the components with the vuex store, which is a new interaction we didn't cover with tests yet. We will first copy and alter the tests and only after we have done that, we will copy the code.

For the 'add todo form', let's first create the test that will force us to write the component.

// tests/unit/components/TodoInput.spec.js
import TodoInput from '@/components/TodoInput'
import { shallowMount } from '@vue/test-utils'

describe('The todo input component', function () {
  it('can be mounted', () => {
    const wrapper = shallowMount(TodoInput)
    expect(wrapper.exists()).toBe(true)
  })
})

And we create the component:

// src/components/TodoInput.vue
<template>
  <div></div>
</template>

<script>
export default {
  name: 'TodoInput'
}
</script>

Now we have the component, let's look in 'todo.spec.js' which test we can copy. I see 3 possible candidates:

    it('allows for adding one todo item', async () => {
      await addTodo('My first todo item')
      expect(elementText('todos')).toContain('My first todo item')
    })
    it('allows for more than one todo item to be added', async () => {
      await addTodo('My first todo item')
      await addTodo('My second todo item')
      expect(elementText('todos')).toContain('My first todo item')
      expect(elementText('todos')).toContain('My second todo item')
    })
    it('empties the input field when todo has been added', async () => {
      await addTodo('This is not important')
      expect(wrapper.find('[data-testid="todo-input"]').element.value).toEqual('')
    })

In the first 2 tests we check the result of adding a todo using the rendered html. These tests need to be rewritten in order to test the interaction with the vuex store.

Only the last test can be copied as is:

// tests/unit/components/TodoInput.spec.js
import TodoInput from '@/components/TodoInput'
import { shallowMount } from '@vue/test-utils'

describe('The todo input component', function () {
  let wrapper

  async function addTodo (todoText) {
    wrapper.find('[data-testid="todo-input"]').setValue(todoText)
    await wrapper.find('[data-testid="todo-submit"]').trigger('click')
  }

  it('can be mounted', () => {
    wrapper = shallowMount(TodoInput)
    expect(wrapper.exists()).toBe(true)
  })
  it('empties the input field when todo has been added', async () => {
    wrapper = shallowMount(TodoInput)
    await addTodo('This is not important')
    expect(wrapper.find('[data-testid="todo-input"]').element.value).toEqual('')
  })
})

Let's fix the test by copying only the code that is needed to get it pass:

// src/components/TodoInput.vue
<template>
  <div>
    <input
      type="text"
      data-testid="todo-input"
      placeholder="Add todo item..."
      class="border border-gray-300 p-1 text-blue-700"
      v-model="newTodo">
    <button
        class="px-3 py-1 text-white bg-blue-500 mb-4"
        data-testid="todo-submit"
        @click.prevent="addTodo">Add
    </button>
  </div>
</template>

<script>
export default {
  name: 'TodoInput',

  data () {
    return {
      newTodo: ''
    }
  },

  methods: {
    addTodo () {
      // this.$store.commit('ADD_TODO', this.newTodo)
      this.newTodo = ''
    }
  }
}
</script>

I commented out the call to the store, because in the test, we haven't defined a store yet. Apart from that we want a test that forces us to uncomment this line.

Before copying and modifying the other tests, we will need to add a store as we did in the original test, but now we are going to create a dummy store with only one mutation: ADD_TODO. We implement this mutation using a jest mock function so we can spy on the calls to this function:

// tests/unit/components/TodoInput.spec.js
import TodoInput from '@/components/TodoInput'
import { createLocalVue, shallowMount } from '@vue/test-utils'
import Vuex from 'vuex'

const localVue = createLocalVue()
localVue.use(Vuex)
let store

describe('The todo input component', function () {
  let wrapper

  const mutations = {
    ADD_TODO: jest.fn()
  }

  beforeEach(() => {
    store = new Vuex.Store({
      mutations
    })
    wrapper = shallowMount(TodoInput, {
      localVue,
      store
    })
  })

  async function addTodo (todoText) {
    wrapper.find('[data-testid="todo-input"]').setValue(todoText)
    await wrapper.find('[data-testid="todo-submit"]').trigger('click')
  }

  it('can be mounted', () => {
    expect(wrapper.exists()).toBe(true)
  })
  it('empties the input field when todo has been added', async () => {
    await addTodo('This is not important')
    expect(wrapper.find('[data-testid="todo-input"]').element.value).toEqual('')
  })
})

Now we have created the mock store, used it for the creation of the wrapper, and checked that the two tests still pass. The remaining tests can now be copied and rewritten to check if the jest spy has been called with right arguments.

// tests/unit/components/TodoInput.spec.js
  ...
  const mutations = {
    ADD_TODO: jest.fn()
  }
  ...

  it('allows for adding one todo item', async () => {
    await addTodo('My first todo item')
    // Note the first param is an empty object. That's the state the commit will be called with.
    // We didn't initialize any state, which causes the state to be an empty object.
    expect(mutations.ADD_TODO).toHaveBeenCalledWith({}, 'My first todo item')
  })
  it('allows for more than one todo item to be added', async () => {
    await addTodo('My first todo item')
    await addTodo('My second todo item')
    expect(mutations.ADD_TODO).toHaveBeenCalledTimes(2)
    // Note the first param is an empty object. That's the state the commit will be called with.
    // We didn't initialize any state, which causes the state to be an empty object.
    expect(mutations.ADD_TODO).toHaveBeenCalledWith({}, 'My first todo item')
    expect(mutations.ADD_TODO).toHaveBeenCalledWith({}, 'My second todo item')
  })

All we have to do to make these tests pass, is to uncomment the line in the component which calls the store:

// src/components/TodoInput.vue
  methods: {
    addTodo () {
      this.$store.commit('ADD_TODO', this.newTodo)
      this.newTodo = ''
    }
  }

One more test passes, but the last test fails with the following message:

Error: expect(jest.fn()).toHaveBeenCalledTimes(expected)

Expected number of calls: 2
Received number of calls: 4

The commit function was called 4 times instead of 2. The reason is that we didn't clear the mock function between tests, so the function accumulates all the calls. We can fix this by clearing all the mocks in the beforeEach function.

// tests/unit/components/TodoInput.spec.js
  ...
  beforeEach(() => {
    jest.clearAllMocks()
    store = new Vuex.Store({
      mutations
    })
    ...
  })
  ...

Now all tests pass. Let's cleanup the tests by removing the first test (can be mounted), because it is obsolete. We can also extract a function which checks if our commit spy has been called so the test is more readable. The complete test file now looks like:

// tests/unit/components/TodoInput.spec.js
import TodoInput from '@/components/TodoInput'
import { createLocalVue, shallowMount } from '@vue/test-utils'
import Vuex from 'vuex'

const localVue = createLocalVue()
localVue.use(Vuex)
let store

describe('The todo input component', function () {
  let wrapper

  const mutations = {
    ADD_TODO: jest.fn()
  }

  beforeEach(() => {
    jest.clearAllMocks()
    store = new Vuex.Store({
      mutations
    })
    wrapper = shallowMount(TodoInput, {
      localVue,
      store
    })
  })

  async function addTodo (todoText) {
    wrapper.find('[data-testid="todo-input"]').setValue(todoText)
    await wrapper.find('[data-testid="todo-submit"]').trigger('click')
  }

  function expectMutationToHaveBeenCalledWith (item) {
    // Note the first param is an empty object. That's the state the commit will be called with.
    // We didn't initialize any state, which causes the state to be an empty object.
    expect(mutations.ADD_TODO).toHaveBeenCalledWith({}, item)
  }

  it('empties the input field when todo has been added', async () => {
    await addTodo('This is not important')
    expect(wrapper.find('[data-testid="todo-input"]').element.value).toEqual('')
  })
  it('allows for adding one todo item', async () => {
    await addTodo('My first todo item')
    expectMutationToHaveBeenCalledWith('My first todo item')
  })

  it('allows for more than one todo item to be added', async () => {
    await addTodo('My first todo item')
    await addTodo('My second todo item')
    expect(mutations.ADD_TODO).toHaveBeenCalledTimes(2)
    expectMutationToHaveBeenCalledWith('My first todo item')
    expectMutationToHaveBeenCalledWith('My second todo item')
  })
})

This finishes the input component. The code can be found on github

Step 2: extract the todo list

We create the list of todo items component the same way as the form:

we force ourselves to create the component
we try to copy tests from the original component
we add the store to the tests

I will not discuss the forcing of the creation of the component anymore. You can find it in the test file as the first test (which I will leave in the code).

There are 2 tests from the original component covering the functionality of the list component:

    it('displays the items in the order they are entered', async () => {
      await addTodo('First')
      await addTodo('Second')
      expect(elementText('todo-0')).toMatch('First')
      expect(elementText('todo-1')).toMatch('Second')
    })
    it('items can be marked as done by clicking an element before the item.', async () => {
      function itemIsDone (itemId) {
        return wrapper.find(`[data-testid="todo-${itemId}"]`).attributes('data-done') === 'true'
      }

      await addTodo('First')
      await addTodo('Second')

      expect(itemIsDone(0)).toBe(false)
      await wrapper.find('[data-testid="todo-0-toggle"]').trigger('click')
      expect(itemIsDone(0)).toBe(true)
    })

We need to change these tests considerably to be useful in our new component because we should test that:

the displayed todo items are retrieved from the vuex store.
toggling of items is done using a store mutation.

We will mock both interactions by extending our mock store. Let's start with list of items:

// tests/unit/components/TodoList.spec.js
import { createLocalVue, shallowMount } from '@vue/test-utils'
import TodoList from '@/components/TodoList'
import Vuex from 'vuex'

const localVue = createLocalVue()
localVue.use(Vuex)
let store

describe('The TodoList component', function () {
  let wrapper

  const getters = {
    todos: jest.fn(() => [{
      description: 'First',
      done: false
    }, {
      description: 'Second',
      done: false
    }])
  }

  beforeEach(() => {
    store = new Vuex.Store({
      getters
    })
    wrapper = shallowMount(TodoList, {
      localVue,
      store
    })
  })

  it('can be mounted', () => {
    expect(wrapper.exists()).toBe(true)
  })
})

We mocked the store todos getter using the possibility of the jest mock function to return an implementation. Now we are ready to copy and modify the test which checks the order of the items:

// tests/unit/components/TodoList.spec.js
    ...
    function elementText (testId) {
      return wrapper.find(`[data-testid="${testId}"]`).text()
    }
    ...
    it('displays the items in the order they are present in the store', async () => {
      expect(elementText('todo-0')).toMatch('First')
      expect(elementText('todo-1')).toMatch('Second')
    })
    ...

And of course it fails. Lets copy just enough code from the original component to make this test pass:

// src/components/TodoList.vue
<template>
  <ul data-testid="todos" class="text-left">
    <li
        v-for="(todo, todoKey) of todos"
        :data-testid="`todo-${todoKey}`"
        :data-done="todo.done"
        :key="todoKey"
        class="block mb-3"
        :class="todo.done ? 'done' : ''"
    >
        <span
            :data-testid="`todo-${todoKey}-toggle`"
            @click.prevent="toggle(todo)"
            class="checkbox"
            :class="todo.done ? 'done' : ''"
        > {{ todo.done ? "Done" : "Mark done" }}</span>
      {{ todo.description }}
    </li>
  </ul>
</template>

<script>
import { mapGetters } from 'vuex'

export default {
  name: 'TodoList',

  computed: {
    ...mapGetters(['todos'])
  }
}
</script>

And it passes. To be sure we are really using the store, we add a check to ensure the getter is called.

// tests/unit/components/TodoList.spec.js
  beforeEach(() => {
    jest.clearAllMocks()
    ...
  })
  ...
  it('displays the items in the order they are present in the store', async () => {
    expect(getters.todos).toHaveBeenCalledTimes(1)
    expect(elementText('todo-0')).toMatch('First')
    expect(elementText('todo-1')).toMatch('Second')
  })
  ...

Note that in order for this test to pass we had to clear all the mocks as we did earlier, so we only count the calls of this specific test.

The only thing left to check is the toggle. When a todo is set to done, a mutation should have been committed to the store. First we prepare our mock store for this mutation:

// tests/unit/components/TodoList.spec.js
  ...
  const mutations = {
    TOGGLE_TODO: jest.fn()
  }

  beforeEach(() => {
    jest.clearAllMocks()
    store = new Vuex.Store({
      getters,
      mutations
    })
    ...
  })
  ...

And then we create the test:

// tests/unit/components/TodoList.spec.js
  it('items can be marked as done by clicking an element before the item.', async () => {
    await wrapper.find('[data-testid="todo-0-toggle"]').trigger('click')
    expect(mutations.TOGGLE_TODO).toHaveBeenCalledWith({}, {
      description: 'First',
      done: false
    })
  })

We make this test pass by copying the toggle method from Todo.vue:

// src/components/TodoList.vue
import { mapGetters } from 'vuex'

export default {
  name: 'TodoList',

  computed: {
    ...mapGetters(['todos'])
  },

  methods: {
    toggle (todo) {
      this.$store.commit('TOGGLE_TODO', todo)
    }
  }
}

This finishes the TodoList component. The code can be found on github.

Step 3: using the new components

Now we have the new components, we can rewrite the old component, so it uses these new components. We have the 'integration' test to check if it still works:

<template>
  <div>
    <h2 class="mb-4">{{ title }}</h2>
    <TodoInput />
    <TodoList />
  </div>
</template>

<script>
import TodoInput from '@/components/TodoInput'
import TodoList from '@/components/TodoList'

export default {
  name: 'Todo',

  components: {
    TodoInput,
    TodoList
  },

  props: {
    title: {
      type: String,
      required: true
    }
  }
}
</script>

And it fails! What happened? Not to worry, this was expected. In the test we use shallowMount, but we extracted components, so we need to use mount which does render the subcomponents:

// tests/unit/components/Todo.spec.js
import { mount, createLocalVue } from '@vue/test-utils'
import Vuex from 'vuex'
import Todo from '@/components/Todo'
import { createStore } from '@/store'

const localVue = createLocalVue()
localVue.use(Vuex)
let store

describe('The Todo.vue component', () => {
  beforeEach(() => {
    store = createStore()
  })
  it('Displays the title when passed as a prop', () => {
    const wrapper = mount(Todo, {
      localVue,
      store,
      propsData: {
        title: 'A random title'
      }
    })
    expect(wrapper.text()).toMatch('A random title')
    const wrapper2 = mount(Todo, {
      localVue,
      store,
      propsData: {
        title: 'Another random one'
      }
    })
    expect(wrapper2.text()).toMatch('Another random one')
  })
  describe('adding todo items', () => {
    let wrapper

    beforeEach(() => {
      wrapper = mount(Todo, {
        localVue,
        store,
        propsData: {
          title: 'My list'
        }
      })
    })

    async function addTodo (todoText) {
      wrapper.find('[data-testid="todo-input"]').setValue(todoText)
      await wrapper.find('[data-testid="todo-submit"]').trigger('click')
    }

    function elementText (testId) {
      return wrapper.find(`[data-testid="${testId}"]`).text()
    }

    it('allows for adding one todo item', async () => {
      await addTodo('My first todo item')
      expect(elementText('todos')).toContain('My first todo item')
    })
    it('allows for more than one todo item to be added', async () => {
      await addTodo('My first todo item')
      await addTodo('My second todo item')
      expect(elementText('todos')).toContain('My first todo item')
      expect(elementText('todos')).toContain('My second todo item')
    })
    it('empties the input field when todo has been added', async () => {
      await addTodo('This is not important')
      expect(wrapper.find('[data-testid="todo-input"]').element.value).toEqual('')
    })
    it('displays the items in the order they are entered', async () => {
      await addTodo('First')
      await addTodo('Second')
      expect(elementText('todo-0')).toMatch('First')
      expect(elementText('todo-1')).toMatch('Second')
    })
    it('items can be marked as done by clicking an element before the item.', async () => {
      function itemIsDone (itemId) {
        return wrapper.find(`[data-testid="todo-${itemId}"]`).attributes('data-done') === 'true'
      }

      await addTodo('First')
      await addTodo('Second')

      expect(itemIsDone(0)).toBe(false)
      await wrapper.find('[data-testid="todo-0-toggle"]').trigger('click')
      expect(itemIsDone(0)).toBe(true)
    })
  })
})

Now it passes, and we are done! The code can be found on github.

Conclusion

This episode ends this series of Vue TDD by example. I created this series because I missed the refactoring part in the resources I found on TDD in Vue.

If you want to learn more there are more resources online. I learned a lot from:

Learn TDD in Vue
Outside-In Frontend Development
The book 'Test-driven development: By example', by Kent Beck

Vue TDD by example episode 2: add vuex store

Jur de Vries — Tue, 18 Aug 2020 09:37:53 +0000

In the previous episode we created a todo app using Test Driven Development. The idea is that it is easier to refactor code once there are unit tests. In this episode we will start refactoring the previously build app.

The changed requirement

We created a very simple todo component. Now suppose we have a big Vue application in which the todo functionality is only one of the functionalities. Apart from that: in the future we want the todos to be visible from anywhere in the app, but the add-form only on a dedicated place. What to do? First thing is that we need a central location for the state. We will solve this by adding Vuex to the mix and creating a store module for the todos.

We will start where the previous tutorial ended. You can find the code to start with on github

The plan for adding the store

When we move the data storage from the components state to a vuex store module, the existing public interface should not change: the end user should not see any difference in the component.
Getting data from and mutating data in the store however should be regarded as the public interface of a component as well, so that would mean we should write unit tests for these interactions.
Let's defer the writing of these tests for now. Because the idea of tdd is to do small steps, we will decide later if and how we will test the integration of the store in the todo component.
What we will do first is:

Create a todo store using TDD
Change the implementation of the todo component, so it uses the store instead of local data, without adding tests to the existing test suite.

Step 0: Add Vuex

In order to use the vuex store, we have to add it to the project. This is a simple procedure using the vue cli:

vue add vuex

After having performed this command, there should be an empty store in your project and it should have been added in main.js.

The code can be found on github

Step 1: create the todo module

First we need a test which forces us to write the code for the store. Let's start with the simplest of all items in a store: the state. We will use a function to create the initial state (an explanation about why to use a function can be found at the vuex documentation).

Let's create our first failing test:

// tests/unit/store/todo.spec.js

import todo from '@/store/todo.js'

describe('The todo store', () => {
  it('uses a function to generate the initial state', () => {
    const newState = todo.state()
    expect(newState).not.toBeUndefined()
  })
})

The first error is that the file could not be found, as expected. Let's add the file with a default export containing the whole store module:

// src/store/todo.js

export default {
  state: () => {}
}

After checking that this really fails, we make the test pass by simply returning an empty object:

// src/store/todo.js

export default {
  state: () => {
    return {}
  }
}

Okay, on to the next test. Let's define the datastructure:

  it('stores the todos at the todos key', () => {
    const newState = todo.state()
    expect(newState).toEqual({ todos: [] })
  })

And it fails. Let's make it pass:

export default {
  state: () => {
    return {
      todos: []
    }
  }
}

Now we have defined the state, let's add the mutation to add a todo using a nested suite which describes all the mutations:

  describe(', the mutations', () => {
    it('a todo can be added using the ADD_TODO mutation', () => {
      const state = todo.state()
      todo.mutations.ADD_TODO(state, 'A random todo description')
      expect(state).toEqual({
        todos: [{
          description: 'A random todo description',
          done: false
        }]
      })
    })
  })

And implement it (we will skip the adding of a function that does nothing to speed up the process):

  mutations: {
    ADD_TODO (state) {
      state.todos.push({
        description: 'A random todo description',
        done: false
      })
    }
  }

Now let's add a second test to force us to really use the description:

    it('a todo can be added using the ADD_TODO mutation passing a description', () => {
      const state = todo.state()
      todo.mutations.ADD_TODO(state, 'Another random todo description')
      expect(state).toEqual({
        todos: [{
          description: 'Another random todo description',
          done: false
        }]
      })
    })

And we can get this to pass using:

  mutations: {
    ADD_TODO (state, description) {
      state.todos.push({
        description,
        done: false
      })
    }
  }

You might ask: do we really need to add all these tiny steps? The answer is: 'no, not always'. In many cases you can work more coarse-grained but remember you can always get back to the simple fine-grained steps if the solutions you want to create is hard to understand. For the rest of the tutorial I will omit the fine-grained steps.

Now we want to add more than one todo and assure that the order in which they are entered will be preserved:

    it('the order in which the todos are added are preserved in the state', () => {
      const state = todo.state()
      todo.mutations.ADD_TODO(state, 'First todo')
      todo.mutations.ADD_TODO(state, 'Second todo')
      expect(state).toEqual({
        todos: [
          {
            description: 'First todo',
            done: false
          },
          {
            description: 'Second todo',
            done: false
          }
        ]
      })
    })

This test passes, as we already expected. We want to be sure this is the case though, which is the reason we added it. Now we can start refactoring the tests, as one of the tests is redundant, and we can move the initialisation of the state to a beforeEach function. The test file looks like now:

import todo from '@/store/todo.js'

describe('The todo store', () => {
  it('stores the todos at the todos key', () => {
    const newState = todo.state()
    expect(newState).toEqual({ todos: [] })
  })

  describe(', the mutations', () => {
    let state

    beforeEach(() => {
      state = todo.state()
    })
    it('a todo can be added using the ADD_TODO mutation', () => {
      todo.mutations.ADD_TODO(state, 'A random todo description')
      expect(state).toEqual({
        todos: [{
          description: 'A random todo description',
          done: false
        }]
      })
    })
    it('the order in which the todos are added are preserved in the state', () => {
      todo.mutations.ADD_TODO(state, 'First todo')
      todo.mutations.ADD_TODO(state, 'Second todo')
      expect(state).toEqual({
        todos: [
          {
            description: 'First todo',
            done: false
          },
          {
            description: 'Second todo',
            done: false
          }
        ]
      })
    })
  })
})

In order to finish the mutations, we also need to be able to toggle the status of a todo:

    it('has a mutation to toggle the status of a todo', () => {
      state = {
        todos: [
          {
            description: 'First todo',
            done: false
          },
          {
            description: 'Todo to toggle',
            done: false
          }
        ]
      }
      todo.mutations.TOGGLE_TODO(state, {
        description: 'Todo to toggle',
        done: false
      })
      expect(state.todos).toEqual([
        {
          description: 'First todo',
          done: false
        },
        {
          description: 'Todo to toggle',
          done: true
        }
      ])
    })

This can be implemented using:

    TOGGLE_TODO (state, targetTodo) {
      const todo = state.todos.find(item => item.description === targetTodo.description)
      if (todo) {
        todo.done = !todo.done
      }
    }

Note that we use the description of the todo as an id. It might be better to generate an id but for simplicity we stick to the description. Also, in almost all cases the todo we pass to the mutation will be the same object as the todo in the list, but we cannot rely on this. For this reason we perform a lookup of the todo item based on the description.

The only thing we have left for the store is a getter to get all the todos:

  describe('the getters', () => {
    const state = {
      todos: [
        {
          description: 'First todo',
          done: false
        },
        {
          description: 'Second todo',
          done: false
        }
      ]
    }
    const todos = todo.getters.todos(state)
    expect(todos).toEqual([
      {
        description: 'First todo',
        done: false
      },
      {
        description: 'Second todo',
        done: false
      }
    ])
  })

And lets fix this:

  getters: {
    todos (state) {
      return state.todos
    }
  }

We have all the tests, but they don't read well. That is an assignment for you: what would you do to make the test more readable? You can find my solution in the repo.

The code till now can be found on github

Aside: what is a unit in case of the vuex store?

When writing the last part it kind of struck me that in testing the store module the internal state of the module is exposed regularly in the tests. Although in the official documentation of the vuex store testing this is the suggested way, it feels to me like testing the implementation to much. What if we want to alter the way the information is stored?

In fact, we can ask ourselves: what is a unit? If you compare a store module to a class, you could argue that the store module is a kind of class in which the actions, mutations and getters are the public interface. If you follow this reasoning it would mean that you only test the store using the public interface, which would mean you would create a real vuex store first and start testing that.

I may elaborate more on this in a separate post, but for now I leave it as is.

Step 2: use the store in the component

Before we can even use the store in our component tests, we need to do two things:

Add the todo module to the store
Ensure we use the store in our test suite by using a local copy of vue.

Adding our new store module to the store is almost trivial:

// src/store/index.js

import Vue from 'vue'
import Vuex from 'vuex'
import todo from '@/store/todo'

Vue.use(Vuex)

export default new Vuex.Store({
  ...
  modules: {
    todo
  }
})

Note that we didn't namespace the module. This is intended.

In order to use the store in the test we need to create a local vue instance and indicate that this local vue instance uses our store:

import { shallowMount, createLocalVue } from '@vue/test-utils'
import Vuex from 'vuex'
import Todo from '@/components/Todo'
import store from '@/store'

const localVue = createLocalVue()
localVue.use(Vuex)


describe('The Todo.vue component', () => {
  ...
  // Add the localVue to the mounting options every time when a mount is done.  
  const wrapper = shallowMount(Todo, {
    localVue,
    store,
    propsData: {
      title: 'A random title'
    }
  })
  ...  
})

Now we can start refactoring the component so it uses the store instead of the local data. Note that we don't alter the tests yet! The diff looks like:

// src/components/Todo.vue

<script>
+import { mapGetters } from 'vuex'
+
 export default {
   name: 'Todo',

+  computed: {
+    ...mapGetters(['todos'])
+  },
+
   data () {
     return {
-      todos: [],
       newTodo: ''
     }
   },

   methods: {
     addTodo () {
-      this.todos.push({
-        description: this.newTodo,
-        done: false
-      })
+      this.$store.commit('ADD_TODO', this.newTodo)
       this.newTodo = ''
     },
     toggle (todo) {
-      todo.done = !todo.done
+      this.$store.commit('TOGGLE_TODO', todo)
     }
   }

And all tests pass except one:

 FAIL  tests/unit/components/Todo.spec.js
  ● The Todo.vue component › adding todo items › displays the items in the order they are entered

    expect(received).toMatch(expected)

    Expected substring: "First"
    Received string:    "Mark done
          My first todo item"

      65 |       await addTodo('First')
      66 |       await addTodo('Second')
    > 67 |       expect(elementText('todo-0')).toMatch('First')
         |                                     ^
      68 |       expect(elementText('todo-1')).toMatch('Second')
      69 |     })
      70 |     it('items can be marked as done by clicking an element before the item.', async () => {

      at Object.it (tests/unit/components/Todo.spec.js:67:37)

This is caused by the fact that we use the same instance of the store in every test. Instead, we want a fresh store at the start of each test. We can fix this by altering the store index file and adding a createStore function which we export:

// src/store/index.js

import Vue from 'vue'
import Vuex from 'vuex'
import todo from '@/store/todo'

Vue.use(Vuex)

export function createStore () {
  return new Vuex.Store({
    state: {},
    mutations: {},
    actions: {},
    modules: {
      todo
    }
  })
}

export default createStore()

Now we can use this function to create a new store for each test:

// src/components/Todo.vue

import { createStore } from '@/store'

const localVue = createLocalVue()
localVue.use(Vuex)
let store

describe('The Todo.vue component', () => {
  beforeEach(() => {
    store = createStore()
  })
  ...
})

All unit tests pass again! We successfully moved the state from the component to the vuex store.

The code so far can be found on github

The missing tests

Although we successfully refactored the code, we still have the problem that the store can be regarded as an input for, and output of the component. In the existing tests we do not take this into account. There is a even a bigger problem: strictly speaking the test looks more like an integration test than a unit test right now.

Question is: is this a problem? I don't think so. I even think it is an advantage! We got ourselves our first integration test.

Of course we are not done yet. Remember that the reason we did the refactoring is that we wanted to have the form for adding a todo separate from the display. There is absolutely no reason for the refactoring we just did if we stopped here. In the next episode we will start extracting the form and the display components. We will need to write the unit tests in which the store is either an input to or an output of the new component.

Vue TDD by example: create Todo app

Jur de Vries — Thu, 06 Aug 2020 12:25:44 +0000

Vue TDD by example: create Todo app.

This blog will be the first in a series about Test Driven Development in VueJs.
I will follow the steps of test driven development:

Create a failing test
Make it pass in the most simple way
Refactor
Continue with adding a new failing test

If you are new to TDD it might feel weird to do all the tiny steps, but I advise you to follow along to get a grasp of it.

Prerequisites

In order to follow this tutorial you need the following:

Basic knowledge about testing with Vue
Experience in Vue and the Vue CLI

Step 0: setting the stage

Before we can do anything, we need to create a new empty Vue project. In order to do that we use the Vue cli:

vue create vue-tdd-todo

Now choose 'manually select features' and check the following:

Babel
Linter
Unit testing

Then for the linter choose 'ESLint + standard config'. The rest of the lint features is of your own choice.
For unit testing choose:

Jest

And for placing config choose 'In dedicated config files'. Now npm should be installing all the code.

For css we will use tailwindcss, so the page we are about to create is not plain old ugly html (although I have absolutely no problem with that...).

npm install -D tailwindcss

And then

// postcss.config.js
const autoprefixer = require('autoprefixer');
const tailwindcss = require('tailwindcss');

module.exports = {
  plugins: [
    tailwindcss,
    autoprefixer,
  ],
};

Now we need to import Tailwind CSS into our project (I also added a base style for h1).

/* src/assets/styles/base.css */
@tailwind base;

h1 {
  @apply text-2xl font-bold;
}

@tailwind components;
@tailwind utilities;

// src/main.js
import Vue from 'vue'
import App from './App.vue'

import './assets/styles/base.css'

Vue.config.productionTip = false

new Vue({
  render: h => h(App)
}).$mount('#app')

We are ready to add some tailwind styles in the future when needed. From now on I will not elaborate on the styles that I set to the various elements, as that is not the aim of this tutorial.

Let's empty the existing content of App.vue so we only have a title "Todo".

<template>
  <div id="app" class="container">
    <h1>Todo</h1>
  </div>
</template>

<script>

export default {
  name: 'App'
}
</script>

<style>
#app {
  @apply mx-auto text-center;
}

h1 {
  @apply text-2xl font-bold;
}
</style>

As a last thing, we delete unneeded files the Vue cli added:

src/assets/logo.png
src/components/HelloWorld.vue
tests/unit/example.spec.js

Te code can be found on github.

Step 1: The component

The aim is to create a component in which we can add and check todo items. Following the rules of TDD the first test that we should write is a test that forces us to create the component.

// tests/components/Todo.spec.js
import { shallowMount } from '@vue/test-utils'
import Todo from '@/components/Todo'

describe('The Todo.vue component', () => {
  it('Can be mounted', () => {
    const wrapper = shallowMount(Todo)
    expect(wrapper.exists()).toBeTruthy()
  })
})

Now run the test using npm run test:unit or use your IDE by creating a run configuration for the tests.

And it fails. That's good news, because now we know the test is actually working. If it passed the test would not have worked correctly. Now we need to create the component.

<template>
  <div>
    <h2>My List</h2>
  </div>
</template>

<script>
export default {
  name: 'Todo'
}
</script>

If we import this component in our test, the test passes. Success! Now we can proceed to the next test.
Let's make the displayed title in the component a prop. The test for this would be:

  it('Displays the title when passed as a prop', () => {
    const wrapper = shallowMount(Todo, {
      propsData: {
        title: 'A random title'
      }
    })
    expect(wrapper.text()).toMatch('A random title')
  })

Notice the title "A random title". I put these words to indicate to the reader of the test that the title is really random and not a 'magic' string. A well written test serves as documentation for your component as well so always strive for clearness.

And of course the test fails if we run it. Let's make it pass.

<template>
  <div>
    <h2>A random title</h2>
  </div>
</template>

<script>
export default {
  name: 'Todo'
}
</script>

And it passes. But wait! That's complete bullshit! The title is hardcoded! Well, that's the idea of TDD. Make the test pass in the most easy and degenerate way, and that's exactly what we did here. In this case it might be a little artificial but when you create a difficult algoritm it can really help you.

Now let's refactor. In the code there is not much to refactor right now, but in the tests there is: the first test is redundant due to the fact that in the second test we successfully mounted the component. So we can delete the first test.

By writing the next test we should get rid of the hardcoded title. How about setting a different title?

  it('Displays the second title when passed as a prop', () => {
    const wrapper = shallowMount(Todo, {
      propsData: {
        title: 'Another random one'
      }
    })
    expect(wrapper.text()).toMatch('Another random one')
  })

Now we really have to start implementing it the right way so let's do that.

<template>
  <div>
    <h2>{{ title }}</h2>
  </div>
</template>

<script>
export default {
  name: 'Todo',

  props: {
    title: {
      type: String,
      required: true
    }
  }
}
</script>

And the tests pass... We have 2 tests for the same functionality though. Maybe just put them together?

  it('Displays the title when passed as a prop', () => {
    const wrapper = shallowMount(Todo, {
      propsData: {
        title: 'A random title'
      }
    })
    expect(wrapper.text()).toMatch('A random title')
    const wrapper2 = shallowMount(Todo, {
      propsData: {
        title: 'Another random one'
      }
    })
    expect(wrapper2.text()).toMatch('Another random one')
  })

There is a rule in TDD which states that there should only be one assert in each test and this test seems to violate this. But think again: are we really asserting two times here, or could these assertions be regarded as one?
As you can see refactoring both the code and the tests is an important part of the process.

Now the basic component is ready, we can add it in the App.vue file, so we can actually see something:

<template>
  <div id="app" class="container">
    <h1>Todo</h1>
    <Todo title="My List"/>
  </div>
</template>

<script>
import Todo from '@/components/Todo'

export default {
  name: 'App',

  components: {
    Todo
  }
}
</script>

Te code can be found at: github

Step 2: adding an item

The next thing to do is to enable the creation of todo items. In order to do that we need an input element and a submit button. Again we write the test first. For selecting elements we make use of a special data-attribute: data-testid. We will also check for only one todo item. Notice the async await, because we have to wait for the click to be done.

  it('allows for adding one todo item', async () => {
    const wrapper = shallowMount(Todo, {
      propsData: {
        title: 'My list'
      }
    })
    wrapper.find('[data-testid="todo-input"]').setValue('My first todo item')
    await wrapper.find('[data-testid="todo-submit"]').trigger('click')
    expect(wrapper.find('[data-testid="todos"]').text()).toContain('My first todo item')
  })

And of course it fails, so let's try to implement it.

<template>
  <div>
    <h2>{{ title }}</h2>
    <input type="text" data-testid="todo-input" v-model="newTodo">
    <button data-testid="todo-submit" @click.prevent="addTodo">Add</button>
    <div data-testid="todos">
      {{ todos }}
    </div>
  </div>
</template>

<script>
export default {
  name: 'Todo',

  props: {
    title: {
      type: String,
      required: true
    }
  },

  data () {
    return {
      todos: '',
      newTodo: ''
    }
  },

  methods: {
    addTodo () {
      this.todos = this.newTodo
    }
  }

}
</script>

This passes but of course its plain ugly. There is not even an array of todos! Just a string. Remember that the idea of TDD is that you first focus on making it work, than on making it right. So how do we make it right? By writing another test that forces us to transform the todos into an array.

  it('allows for more than one todo item to be added', async () => {
    const wrapper = shallowMount(Todo, {
      propsData: {
        title: 'My list'
      }
    })
    wrapper.find('[data-testid="todo-input"]').setValue('My first todo item')
    await wrapper.find('[data-testid="todo-submit"]').trigger('click')
    wrapper.find('[data-testid="todo-input"]').setValue('My second todo item')
    await wrapper.find('[data-testid="todo-submit"]').trigger('click')
    expect(wrapper.find('[data-testid="todos"]').text()).toContain('My first todo item')
    expect(wrapper.find('[data-testid="todos"]').text()).toContain('My second todo item')
  })

Which we can implement by:

<template>
  <div>
    <h2>{{ title }}</h2>
    <input type="text" data-testid="todo-input" v-model="newTodo">
    <button data-testid="todo-submit" @click.prevent="addTodo">Add</button>
    <div data-testid="todos">
      <div v-for="(todo, todoKey) of todos" :key="todoKey">
        {{ todo }}
      </div>
    </div>
  </div>
</template>

<script>
export default {
  name: 'Todo',

  props: {
    title: {
      type: String,
      required: true
    }
  },

  data () {
    return {
      todos: [],
      newTodo: ''
    }
  },

  methods: {
    addTodo () {
      this.todos.push(this.newTodo)
    }
  }

}
</script>

As you can see there is only a small change from a single value to an array value. The transformation is really simple! If we look at the tests however we notice that there is duplication in the code. It is also not directly clear what is happening. So let's refactor the tests (we can do that because we have working code which can be used to test the tests!).
The refactorings I want to do are:

Put the add todo tests in it's own test suite.
Extract a method to add a todo.
Extract a method to find element text.

describe('adding todo items', () => {
    let wrapper

    beforeEach(() => {
      wrapper = shallowMount(Todo, {
        propsData: {
          title: 'My list'
        }
      })
    })

    async function addTodo (todoText) {
      wrapper.find('[data-testid="todo-input"]').setValue(todoText)
      await wrapper.find('[data-testid="todo-submit"]').trigger('click')
    }

    function elementText (testId) {
      return wrapper.find(`[data-testid="${testId}"]`).text()
    }

    it('allows for adding one todo item', async () => {
      await addTodo('My first todo item')
      expect(elementText('todos')).toContain('My first todo item')
    })
    it('allows for more than one todo item to be added', async () => {
      await addTodo('My first todo item')
      await addTodo('My second todo item')
      expect(elementText('todos')).toContain('My first todo item')
      expect(elementText('todos')).toContain('My second todo item')
    })
  })

That's a lot better. The tests read well, and we got rid of the duplication. Now let's have a look into the rendered items. We didn't do that till now (there was no need!), but it is advisable to do it from time to time. What we see is that there are some styling issues (it looks ugly) and after adding a todo, the text the input is not cleared when a todo has been added. You can add any style you want or even change the element types (that's wy we used the 'data-testid' attribute!). Notice how the styling has no influence on the tests at all!
We will solve the emptying of the input element by first writing the test.

  it('empties the input field when todo has been added', async () => {
    await addTodo('This is not important')
    expect(wrapper.find('[data-testid="todo-input"]').element.value).toEqual('')
  })

Of course it fails, so let's fix it:

  methods: {
    addTodo () {
      this.todos.push(this.newTodo)
      this.newTodo = ''
    }
  }

As you might notice now is that the writing of a test and the corresponding production code take only a few minutes to write. The cycles are very short. This is the idea of TDD. A red, green refactor cycle should be very short.

Before continuing with marking the todo's as done, there is one test to write: we want the todo items to be displayed in the exact order we entered them, so let's make the test:

    it('displays the items in the order they are entered', async () => {
      await addTodo('First')
      await addTodo('Second')
      expect(elementText('todo-0')).toMatch('First')
      expect(elementText('todo-1')).toMatch('Second')
    })

This only fails because we didn't add the test id's, so let's fix that in the code:

    ...
    <ul data-testid="todos" class="text-left">
      <li
          v-for="(todo, todoKey) of todos"
          :data-testid="`todo-${todoKey}`"
          :key="todoKey"
      >
        {{ todo }}
      </li>
    </ul>
    ...

Te code can be found on github.

Step 3: marking items done

A todo list is useless if we can't mark an item done, so we need an element we can click for each todo item which sets the item to done.

    it('items can be marked as done by clicking an element before the item.', async () => {
      await addTodo('First')
      await addTodo('Second')
      expect(wrapper.find('[data-testid="todo-0-toggle"]').text()).toEqual('Mark done')
      await wrapper.find('[data-testid="todo-0-toggle"]').trigger('click')
      expect(wrapper.find('[data-testid="todo-0-toggle"]').text()).toEqual('Done')
    })

Of course this fails. There is quite a lot to be done in order to get this working: the todos are now stored as a flat list of strings. The most easy way to store the status of the item is to transform the items into objects where we can store the status. Let's do that first.

<template>
    ...
      <li
          v-for="(todo, todoKey) of todos"
          :data-testid="`todo-${todoKey}`"
          :key="todoKey"
      >
        {{ todo.description }}
      </li>
    ...
</template>

<script>
export default {
  ...
  methods: {
    addTodo () {
      this.todos.push({
        description: this.newTodo,
        done: false
      })
      this.newTodo = ''
    }
  }
  ...
}
</script>

Now still the only the last test fails, but we where able to do a quick refactor to allow for setting the item to done. All the earlier tests still succeed so we can be confident the code is still working as expected. Now let's proceed fixing the last test.

<template>
  ...
      <li
          v-for="(todo, todoKey) of todos"
          :data-testid="`todo-${todoKey}`"
          :key="todoKey"
      >
        <span
            :data-testid="`todo-${todoKey}-toggle`"
            @click.prevent="toggle(todo)"
        > {{ todo.done ? "Done" : "Mark done" }}</span>
        {{ todo.description }}
      </li>
  ...
</template>

<script>
export default {
  ...
  methods: {
    ...
    toggle (todo) {
      todo.done = !todo.done
    }
  }
  ...
}
</script>

That was quite easy again. There is a problem though: we check if the todo item is done by looking at the text in the specific element. But what if we want to change the text of this element? Would it not be better to check data in the component?

NO! NEVER TEST IMPLEMENTATION DETAILS!!!!!

The way we implemented if an item is done is an implementation detail we might want to refactor later. This is the whole point of unit tests: you can alter the implementation as long as the public interface stays the same. The unit test is only testing the public interface. When developing Vue, the public interface or output of a component is the rendered html. It might also be a call to a service, or a call to the vuex store, but in this case the only public interface is the template.

The text we check however is also an implementation detail: it has to do with how we display the data and we might want to change that. So lets refactor the way we check if a todo item has been done:

it('items can be marked as done by clicking an element before the item.', async () => {

      function itemIsDone (itemId) {
        return wrapper.find(`[data-testid="todo-${itemId}"]`).attributes('data-done') === 'true'
      }

      await addTodo('First')
      await addTodo('Second')

      expect(itemIsDone(0)).toBe(false)
      await wrapper.find('[data-testid="todo-0-toggle"]').trigger('click')
      expect(itemIsDone(0)).toBe(true)
    })

As you can see I moved the functionality to check if an item is done to a separate function and changed that functionality. The test is easy to read now and by looking at the function the definition when the item is done is easily understandable. This way the test is also more a way to document the functionality. By writing the status of the todo to a data attribute, it is now far easier to change the rendering.

The fixed code in the template looks like this:

<template>
  ...
      <li
          v-for="(todo, todoKey) of todos"
          :data-testid="`todo-${todoKey}`"
          :data-done="todo.done"
          ...
      >
        ...
      </li>
    ...
</template>

As a last step I added some styling without altering any of the functionality.

Te code can be found on github.

And this ends this tutorial. I hope you learned something.