practice

preface

This article is not a complete guide to unit testing, but it will give you some examples of how to write test code to get you thinking, and then give you some advice on how to write unit tests.

Common function

For example, we have written a function to verify the password format (both upper and lower case) as follows:

function isRightPassWord(password) {
  const pattern = new RegExp(/ ^ (? =.*[A-Z])(? =.*[a-z])(? = (. *) [0-9] [a zA - Z0-9] $/ 16th {8});
  const isMatched = pattern.test(password);
  if(! isMatched) {return false;
  }
  return true;
}
Copy the code

So the question is, how do we test it? If we haven’t written any unit tests, it’s really hard to do, we don’t know what the test points are, right? Let’s think about a few questions.

What are you testing?

In this part, we need to describe well what the function corresponding to our test is, which is translated into the code as follows:

describe('isRightPassWord function', () = > {});Copy the code

What is he doing here?

So this is the part where we have to think about what this function does, and we have to think about the marginal case. So this function is to help us check whether the string satisfies both upper and lower case.

test('with empty params', () = > {}); test('with wrong params Aasdfxzs', () = > {}); test('with correct params 123aAbBCc', () = > {});Copy the code

What does Ta actually output? What is the expected output?

In this part, we need to pass the parameters corresponding to the above conditions into the function under test, assert the corresponding expected output, and then run the program to check whether the actual output meets our expectations and convert it into the corresponding code segment, which is as follows:

// with empty params
expect(isRightPassWord()).toBe(false);
// with wrong params Aasdfxzs
expect(isRightPassWord('Aasdfxzs')).toBe(false);
// with correct params 123aAbBCc
expect(isRightPassWord('123aAbBCc')).toBe(true);
Copy the code

The final step is to run the program to see if the actual output matches our expectations, then continue writing the rest of the test code, and then the traffic light game.

There is a problem. According to the above ideas, we supplement the corresponding single test after the function is completed. The actual experience of the process is no different from the direct use in the business layer, but it only helps us maintain the corresponding modules with a layer of guarantee mechanism.

But can we write the corresponding test first, and then write the corresponding function according to the test in the driver? This is the TDD concept. In fact, this is more in line with our coding habits, just part of the preconditions into the corresponding test code.

Explain, can think before writing the code corresponding to the demand, more is to realize the part is how to implement the requirements, and then used in the business logic layer, and modify the corresponding code segment, but such circulation mechanism out of condition, it is intuitive to meet the demand conditions directly, but part of the boundary conditions may be found on the demand during the test, and then back to open loop mechanism, The conditions for breaking out are to fix the corresponding problem and satisfy the immediate conditions.

We worked together to optimize the corresponding process. At the beginning, we would think about the corresponding requirements and break them down into several problems. How do you respond to direct requirements? What are the corresponding marginal cases? Then according to the corresponding problems, write test code, run the test after completion, start to write functions according to the traffic light game.

One of the questions you might have is, does that add up to a lot of time? Of course, thinking is about the same, or there’s just one more step to turn thinking into a test. So our question is how do we reduce the time we spend writing tests? Write more, extract the corresponding model and add it to the editor’s Live Template.

Combining with the Vue

Recommended official tutorial, combined with Australian little brother’s guide to eat. If you use the CLI to create a vm, refer to this section.

To borrow an example from Edd Yerburgh, rewrite as follows:

// src/components/Foo.vue
<template>
  <div class="foo">
    <button id="change-message" @click="changeMessage">Change message</button>
  </div>
</template>
<script>
export default {
  data() {
    return {
      msg: 'Welcome to Your Vue.js App'
    };
  },
  methods: {
    changeMessage() {
      this.msg = 'new message'
    }
  }
}
</script>
Copy the code

Note: you need to install a bunch of dependencies from the Webpack website, and if you build your own project, you need to deal with the loader for Webpack.

// src/components/Foo.spec.js

import { expect } from 'chai'
import { mount } from '@vue/test-utils'
import Foo from './Foo.vue'

describe('Foo.vue', () => {
  it('changes h1 text when #change-text is clicked', () = > {const wrapper = mount(Foo)
    const changeMessage = wrapper.find('#change-message')
    changeMessage.trigger('click')
    const h1 = wrapper.find('h1')
    expect(h1.text()).to.equal('new message')})})Copy the code

@vue/test-utils provides functions that implement different mount methods in the test environment. If you are not sure about the difference between mount methods, check out the corresponding website or some of the concepts in the React unit test notes. The official website also summarizes the corresponding common skills.

Combined with the React

I haven’t written the React test code for a long time, so I won’t describe the corresponding ideas and procedures. After all, the single test method is the same. Check the corresponding official website to provide the corresponding test dependency. But I remember generally testing frameworks using Jest + Enzyme. Enzyme and @vue/test-utils wrap the components and expose the same interface usage habits as jQuery.

How to practice?

Remember the question from the introduction?

Do you trust the code you write?

How do you check code quality?

How do you verify your memory?

Adding single test to our practice, there is indeed a lot of resistance, its role is long-term. Not only does it help us refine our own processes, but it also helps us trigger our own thinking. How do I separate functions from functions to be more consistent with the single rule? How to distinguish functional boundaries? Should single tests emphasize coverage?

reference

  1. Vue official tutorial
  2. Five questions that must be answered for each unit test
  3. Five Traps to Avoid While Unit Testing Vue.js
  4. How to unit test Vue components for beginners
  5. Vue testing handbook