前端单元测试

前端单元测试

背景

• 一直以来，单元测试并不是前端工程师必须具备的一项技能，在国内的开发环境下，普遍都要求快，因此往往会忽略了项目的代码质量，从而影响了项目的可维护性，可扩展性。随着前端日趋工程化的发展，项目慢慢变得复杂，代码越来越追求高复用性，这更加促使我们提高代码质量，熟悉单元测试就显得愈发重要了，它是保证我们代码高质量运行的一个关键。
• 本文旨在探索单元测试的编写思路，它对项目的影响，以及对日常开发习惯的一些思考。会涉及 jest 库，详细环境准备，及API使用规则可以参考 jest官网，这里不做赘述。

概念

• 黑盒测试：不管程序内部实现机制，只看最外层的输入输出是否符合预期。
• E2E测试：(End To End)即端对端测试，属于黑盒测试。 比如有一个加法的功能函数，有入参，有返回值，那么通过编写多个测试用例，自动去模拟用户的输入操作，来验证这个功能函数的正确性，这种就叫E2E测试。
• 白盒测试：通过程序的源代码进行测试，而不是简单的使用用户界面观察测试。本质上就是通过代码检查的方式进行测试。
• 单元测试：针对⼀些内部核心实现逻辑编写测试代码，对程序中的最小可测试单元进行检查和验证。也可以叫做集成测试，即集合多个测试过的单元⼀起测试。它们都属于白盒测试。

如何编写单元测试

• 第一步，先找到测试单元的输入与输出

  如何着手写单元测试呢，首先要知道怎么抓住程序单元的头和尾，即测试临界点。例如现在有个求和函数add，现在要给它写单元测试，那么它的关键节点是什么呢？

  // add.js
  // 求和函数
  module.exports = {
    add(a, b) {
      return a + b;
    },
  };

  ​ 当我们调用add函数时，先会给它传入两个参数，函数执行完，会得到一个结果，所以我们可以以传入参数作为起点(输入)，输出值作为终点(输出)去编写测试用例。

  

  将我们日常开发中的场景可以大致总结如下图所示：

  

• 第二步，测试模型，理清程序的输入输出后，再按如下三步骤编写单元测试

  1. 准备测试数据(given)。
  2. 模拟测试动作(when)。
  3. 验证结果(then)。

  还是以求和函数 add 为例子编写测试套件：

  // add.spec.js
  const { add } = require("./add");
  it("测试add求和函数", () => {
    // given -> 准备测试数据
    const a = 1;
    const b = 1;
  
    // when -> 模拟测试动作
    const result = add(a, b);
    
    // then -> 验证结果
    expect(result).toBe(2); 
   
  });

• 小结

  以上的操作，实际上可以想象为把我们要测试的函数或组件当作成一个冰箱，往冰箱里放一瓶水，过一段时间，会得到一瓶冰水。那么往冰箱放一瓶水是输入，拿出一瓶冰水是输出。我们的程序不管多复杂，也可以按上面这样先找到临界点。这样我们就知道从哪里开始测试，到哪里结束，从而按照测试步骤，模拟程序，论证得到的结果。

TDD模式

上面我们已经了解了如何编写单元测试用例，那我们如何利用单元测试帮助我们合理产出呢？就像上面 add函数的例子，我们是先实现了功能，再去测试功能的。如果单元测试仅仅是用来这样去产出的话，那也未免太鸡肋了。回想一下，我们目前的常规开发模式是拿到需求，实现需求，再去测试我们程序是否达到了交付要求。而TDD模式，则完全颠覆了这个过程，它是先写单元测试用例，通过单元测试用例来确定编写什么样的代码，实现什么样的功能，即测试驱动开发(Test Driven Development)。

• 核心思想

  开发功能代码前，先编写测试代