I have shared the idea of building UI component library and how to realize components before. Today I share the content that I think is the “most” part of developing component library. Repeat (1E8) has (ZEi) meaning (MA) thought (Fan) – unit test. The utility class section is not fully covered. The report is as follows:

preface

This article is roughly divided into three parts, the first part of the simple introduction of unit testing, let you understand its role and advantages. The second part introduces the selection of unit testing technology and its practical application in the project. A simple example will be given to show how to use it. Part 3 shows you how to use integrated services tools to improve our productivity.

Hopefully, by the end of this article, you’ve gotten a feel for the concept of unit testing. Now let’s move on to the main part.

positive

Let me start with two questions.

What are unit tests?

English called Unit Testing, also known as module Testing, is a test for the correctness of the program module. A program unit is the smallest testable part of an application. In procedural programming, a unit is a single program, function, procedure, etc. For object-oriented programming, the smallest unit is a method, including methods in a base class (superclass), an abstract class, or a derived class (subclass).

Pay attention to the following situations:

  1. Tests that require access to a database are not unit tests;
  2. Tests that require access to the network are not unit tests;
  3. Tests that require access to a file system are not called unit tests.

Why do we need unit tests?

I’ve come up with three advantages from unit testing.

1. Hidden feature bugs may be detected

More than once when I was writing unit tests, I came across b when I thought the output should be A. It’s time to revisit your code.

2. Ensure the security of code refactoring

Every component in the component library is likely to be refactored or updated over time, and if unit test coverage is high, potential problems are more likely to be discovered after code changes. For example, some function code was accidentally deleted. This can cause confusion when users update the latest version without previously used features.

3. Easy to test code, resulting from good design

In short, I realized how bad my code was when I started adding unit tests to the component library.

In addition to this, there is a design methodology called Test-driven Development (TDD), which is a core practice and technique in agile development. The code for unit test cases is written before the functional code is developed, and the test code determines what code needs to be written. Another design methodology is called behavior-driven development (BDD). Those who are interested can check it out by themselves.

Let’s move on to the second part, how we use unit tests.

Technology selection

The tools used in unit testing are roughly divided into three parts: management tools, testing framework and assertion library.

I chose Karma, Mocha and Chai, and I’ll talk about each of them.

Karma is a Node.js-based JavaScript Test execution process management tool, also known as Test Runner. Commonly used management tools such as Jest.

Mocha is a feature-rich front-end testing framework. A “test framework” is a tool for running tests. It allows you to add test cases to your JavaScript application to ensure the quality of your code. Mocha can run either in node.js or in a browser. Other commonly used testing frameworks include Asmine, Jasmine, etc.

Chai is an assertion library, similar to Node’s built-in assertions. It makes testing easier by providing many assertions that can be run against your code. The syntax of different assertion libraries is similar. The following figure compares the differences between expect, should, and Assert:

expect(a).to.equal(b) // expect

a.should.equal(b) // should

assert.equal(a, b) // assert
Copy the code

In the above example, A represents the output, b represents the desired result, and all three test examples determine whether A is equal to B.

The following is a real-world example in a project.

Unit Test Examples

The following is an example of Switch components:

There are two pieces of information in the figure, which are four measurement dimensions and markers.

  • Measure the dimensions

Line coverage: Is every line executed

Function coverage: Whether every function is called

Brancch Coverage: Whether every block of if code executes

Statement coverage: Whether each statement is executed

  • tag

‘E’ : ‘else path not taken’, appears in if/else statements, indicating if tested, but not else tested.

‘I’ : ‘if path not taken’, appears in if/else statement, without if test.

‘x (N) ‘: This line is executed several times.

Lines or code segments that are not executed are highlighted in red

Let’s take a look at the Switch unit test code.

import Vue from 'vue'
import { destroyVM, createVue, createTest } from '.. /util'
import Switch from 'packages/switch'

describe('Switch', () = > {let vm
  afterEach((a)= > {
    destroyVM(vm)
  })

  it('use', () => {
    Vue.use(Switch)
    expect(Vue.component(Switch.name))
      .to.be.a('function')
  })

  it('disabled', () => {
    vm = createTest(Switch, {
      disabled: true
    }, true)

    let switchElm = vm.$el.querySelector('.owl-switch-input')
    expect(switchElm.disabled).to.be.true
  })

  it('init callback event', done => {
    const btnHandler = sinon.spy()

    vm = createVue({
      template: ` 
       
       `.data: {
        val: false.color: '# 584628',},methods: {
        handle () {
          return btnHandler()
        }
      }
    })

    expect(btnHandler).to.be.called
    setTimeout((a)= > {
      vm.val = true
      done()
    })
  })
})
Copy the code

A test file can have multiple descriptions. It defines a test case, and the second parameter is a callback function. In the function, the return result provided by the assertion library can be used to determine whether the test case passes or fails.

Interpreting the above code, I create three test cases. The first test case is whether the Switch component can be injected properly. The second test case determines whether a component is disabled when it is set to Disabled. The third test case tests whether the component’s callback event is executed. If you have logic that requires deferred invocation, use the done method.

One side of such a simple component is written. Because there are very few features, there is very little test code to write. Some complex components may have 7 or 8 test cases or more.

Next comes the final part – the integration service tool

Integrated service tools

In our work, we spend a lot of time writing code in addition to developing features. We also spend a lot of time building and testing projects. Using automated tools for build and test will help us save some time and thereby indirectly increase our productivity.

Introduce two integration service tools I’m using, Travis CI and Codecov.

Travis CI

Travis CI provides Continuous Integration services (CI). It binds to projects on Github and automatically grabs new code whenever it comes in. It then provides a runtime environment to perform tests, complete builds, and deploy to the server.

Continuous integration refers to automatically running builds and tests whenever code changes and reporting back the results. After making sure that it is as expected, “integrate” the new code into the trunk.

The benefit of continuous integration is that every time you make a small change to your code, you can see the results, accumulating small changes over time, rather than merging a large chunk of code at the end of the development cycle.

Here I only do a simple introduction, using the tutorial you can click to see more.

Codecov

Codecov provides highly integrated tools to group, merge, archive, and compare coverage reports. Codecov, like Travis CI, supports Github login and syncs projects on Github.

To use NPM I codecov -d, add the codecov command to.travis. Yml. This way, the Travis CI executes one side each time the code changes, and also executes Codecov, pushing the result to Codecov.

They all provide their badges to make your project look more professional.


conclusion

Unit testing has been covered briefly here, but if you want to try unit testing at work, you need to do a lot of practice and application yourself. This process can not avoid the repeated operation of digging and filling pits. I think can persist to the end of not only need to have a strong perseverance, not only need to have a rich knowledge reserve, but need to have a real love for it. I wish you all progress in your studies.