关于单元测试，我们需要知道什么？- 实践篇 - 偏方法论层面

实践篇

前言

本篇并非完整指导读者如何进行单元测试，但是会结合部分例子讲解如何编写测试代码，从而引发读者自行思考，然后会给出编写单元测试途中建议。

普通函数

举个例子，我们自己写了一个校验密码格式（同时满足数字大小写字母）的函数如下：

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

那问题来了，我们如何去进行测试呢？若我们并没有写过任何的单元测验，其实很难下手，我们并不清楚测试点在哪里？那我们一起思考几个问题吧。

你测试的是什么？

这部分我们要描述好，我们对应测试的函数是什么，转化成代码就如下：

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

Ta 是来做什么？

这部分我们需要想想，该函数的作用到底是什么，已经想想对应的边际情况。所以该函数是帮助我们校验字符串是否同时满足数字大小写字母的，想到一个如传空的边际情况，如上思路转成代码，就是如下：

test('with empty params', () => {});

test('with wrong params Aasdfxzs', () => {});

test('with correct params 123aAbBCc', () => {});

Ta 实际输出什么？预期输出什么？

这部分我们需要讲对应的上述条件的参数传入被测函数，断言对应的预期输出，然后运行程序，查看实际输出是否满足我们预期，转化成对应的代码段，就是如下：

// 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);

最后一步，运行程序查看实际输出是否符合我们的预期，然后继续书写其他测试代码，之后便是红绿灯游戏了。

有一个问题，按照上文思路我们是在函数完成后，进行补充对应的单测。过程实际体验上和直接在业务层使用并没有什么差别，只是帮助我们后续维护对应模块有了一层保障机制。

但是能否先写好对应的测试，然后根据测试在驱动我们编写对应的函数呢？这就是TDD概念。其实这样更符合我们的编写代码习惯，只是将部分前置条件转化为对应的测试代码。

解释一下，在编写代码之前会思考对应的需求，更多是实现部分是如何实现该需求，然后边在业务逻辑层使用，边修改对应的代码段，然则这样循环机制中跳出的条件，直观的是满足了直接需求条件，但部分边界条件或许在需求测试期间被发现，然后重新开启循环机制，而跳出的条件就是修复对应问题并满足直接条件。

我们一起优化对应的流程，起点我们会思考对应的需求，将其拆解出若干个问题。如何对应的直接需求？对应的边际情况有哪些？然后根据对应的问题，进行书写测试代码，完成后运行测试，开始根据红绿灯游戏进行编写功能。

这时候你应该会有一个问题，这样做会造成时长大量增多吧？当然，其实思考的时候两者是差不多的，或是只是多了一步将思考转化成对应测试的步骤。那我们的问题简化为如何减少书写测试的时间？多写，提取对应的模型，加入编辑器的 live Template 中。

结合 Vue

推荐官方教程，结合澳大利亚小哥的指南进行食用。若使用的CLI创建，可借鉴此文。

借用Edd Yerburgh文中的一个例子，改写如下：

// 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>

注意：你需要根据官网去安装一堆的依赖包，然后若是自建项目，你需要处理好 Webpack 对应的loader问题。

// 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')
  })
})

@vue/test-utils提供了对应的函数，在测试环境实现了不同的挂载方式，或是你不清楚挂载方式的区别，请查看对应的官网，或是React单元测试笔记中的部分概念。官网也总结了对应的常用技巧。

结合 React

好久没主要写过了 React 测试相关代码，所以就不一一赘述对应的思路以及流程，毕竟单测方式是一样的。查看了对应官网是有提供对应的测试依赖的。但我记得一般都是测试框架使用Jest + Enzyme。Enzyme和@vue/test-utils包裹组件，然后暴露出来的接口使用习惯还是和jQuery的使用习惯差不多的。

如何实践？

还记得引言篇的问题吗？

你是否信任你写的代码吗？

你如何检测代码质量？

你如何验证你的记性？

将单测加入我们实践中，确实存在很多阻力，其作用是长远的。不仅帮助我们细化自身处理方式，还帮助我们引发自身的思考。如何将函数/函数抽离的更符合单一原则？如何区分功能界限？单测要不要强调覆盖率？

baixiaoji / blog