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

476 阅读5分钟

实践篇

前言

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

普通函数

举个例子,我们自己写了一个校验密码格式(同时满足数字大小写字母)的函数如下:

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 + EnzymeEnzyme@vue/test-utils包裹组件,然后暴露出来的接口使用习惯还是和jQuery的使用习惯差不多的。

如何实践?

还记得引言篇的问题吗?

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

你如何检测代码质量?

你如何验证你的记性?

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

参考文献

  1. Vue 官方教程
  2. 【译】每个单元测试必须回答的 5 个问题
  3. Five Traps to Avoid While Unit Testing Vue.js
  4. How to unit test Vue components for beginners
  5. Vue testing handbook