前端测试 —— 技术选型及入门

为什么要撰写前端的测试？

在前端发展日益壮大后，我们在项目中往往引入了工程化、模块化的概念，这和数年前前端极度依赖后端渲染以及切图工作产生了极大的进步，当然这些进步也使得我们的项目变得更加复杂庞大，并且在项目中使用了SPA的应用概念，每个工程的复杂化、代码的高复用性要求和前端代码模块之间的高内聚低耦合的需求，前端工程中的单元测试流程就显得很有其必要。
我们需要明确单元测试存在的必要性，这项技术是为了使得我们不仅仅可以通过自定义的测试用例来测试我们已经写好的功能，更加长久持续的意义在于我们在组件中增删改操作后可以保证我们原先被测试覆盖到的功能可以不受影响，这更有利于降低测试人员的压力，提高测试的效率，可以避免在项目迭代后需要测试人员重新重复测试前几个版本反复测试过的功能。并且在项目复杂度过高后，”人肉测试“这种方式更加容易出现疏漏，漏测一些必要的功能或细节。

前端测试的类型

由于前端的特殊性，我们往往不同于后端通过检测一个方法或模块的输入和输出就可以依赖去撰写一个具有目的性的测试用例。在引入了新式框架Vue、React或Angular后，我们对于组件化的运用越来越多，在改变了组件的状态后往往会触发DOM的更新，所以前端因此衍生出两种测试方式。

• 单元测试 （unit testing）
  单元测试对应为白盒测试
  首先我们需要明确的是什么是单元测试？首先我们假设我们的项目是一个SPA项目，也就是说我们的项目中都是由组件来组成的，在这里提倡的单元测试即为对一个单一的组件进行封闭的测试。为什么说是一个”封闭“的，是因为我们的组件中可能去调用别的工具函数或是会触发别的组件的显示和隐藏，在这里是不在单个测试集合的测试范围中的，我们所需要测试的只是一个组件中自身的逻辑和DOM的反馈状态，不需要去考虑别的组件或是工具函数的影响。这样可以最大程度的降低测试用例的耦合度，使用例专注测试组件中的某个具体的功能。
  同时保留了白盒测试的特性，在引入了vue-test-utils后，我们可以更方便地更改和监听组件本身的props和data（或state）来确定数据的流动和更改，保证整个流程中数据的正确性，并且在异步这类操作的机制下，可以通过单元测试更好地判断各时间点数据是否达到预期。
• E2E测试（end to end）
  端到端测试则对应的为黑盒测试，即只测试输入输出，不考虑过程状态的测试方式，在前端中这种测试方式最简单直白的方式的就是通过一个trigger去触发一个DOM事件，然后通过断言判断页面中的DOM是否符合预期中的更新，很简单很粗暴的方式，当然这种编写的方式相对于单元测试难度也会降低不少，所以在技术足够成熟并且在团队足够强壮时可以交给测试人员去撰写。

技术选型

• 项目框架： Vue
  在项目中选用的为Vue框架，所以这一系列也会以Vue框架为主作为一个切入点，这点在和其他框架的测试用例撰写上会有一定的出入，所以在Vue中也有一个专用的辅助测试工具为vue-test-unils，这个工具会在接下来的教程中演示。
  本系列中会采用最新的vue-cli 3.0来构造整个项目，所以在项目构造中会直接选择各类的需要框架，所以不会演示具体的插件的安装过程。
• 单元测试框架： Jest
  在vue-cli 3.0中提供了两种单元测试选型供我们选择，一种为mocha + chai组合，另一种为facebook出品的Jest框架，在接下来的单元测试专题中会讲解为什么这里选用了Jest框架。
• E2E测试框架： Cypress
  同样的在脚手架中也提供了两种E2E测试所依赖的框架，分别为Nightwatch和Cypress，这里我们选用更新的Cypress，本系列也会着重讲解这款框架API的使用。

结构介绍

在测试中大体写法为一个测试套件describe中包含一个或多个测试用例it或test，在一个测试的集合中也就是一个测试文件中可以有多个测试套件，每一个测试套件和用例都有自己的描述，我们应该在针对一个组件建立一个测试文件，在文件中对应一个或多个desscribe来测试不同类型的功能，然后在一个测试套件中再详细地撰写每一个测试用例的具体测试函数或DOM变化。在一个测试套件中通常测试框架都会提供针对测试用例的自己的生命周期，不同的框架提供的语法可能会有一定的差异，不过可以大致分成四个生命周期，这里我们以单元测试的Jest为例：

• beforeEach 在每个测试用例之前运行
• beforeAll 在所有测试用例之前运行
• afterEach 在每个测试用例之后运行
• afterAll 在所有测试用例之后运行