自动化测试（二）01-前端测试分为单元测试、集成测试和E2E测试 & 测试工具对比-适合TDD或 BDD、断言、异步测试 & 测试工具的类型

自动化测试（二）01-前端测试分为单元测试、集成测试和E2E测试 & 测试工具对比-适合TDD或 BDD、断言、异步测试 & 测试工具的类型

前端自动化测试

测试是一个庞大的主题，包括各种分类的测试，诸如黑盒测试/白盒测试、单元测试/集成测试/端到端测试等。通常程序员在测试自己的代码的时候用得最多的便是单元测试，但是因为测试也是需要代价，很多人是不喜欢写测试的，甚至是一点都不写。

那么是什么原因让大家不愿意写呢？

1. 不熟悉
2. 浪费时间
3. 知识不成体系
4. 团队氛围
5. 缺少实践

我们要从基础的东西学起，打消对测试的恐惧。

测试的分类

在多浏览器的自动化测试，我们多半是进行端到端的测试工作，一小部分是大粒度的单元测试。端到端测试测试模拟用户的行为。在 Web 应用程序中，他们会启动服务器，打开浏览器，模拟用户的行为进行点击、输入、提交等动作，断言浏览器中发生了特定的事情或者是得到了期待的结果，从而让我们相信功能可以正常的运行。

而单元测试根据代码单元的公共 API 运行它们。这些测试需要创建一个类的实例，使用特定的输入调用它的方法，断言被调用的方法达到了预期的效果。在下文中我们会看到这两种测试的实践，当然有时候区分度并不大，可能无法明显地区分哪些是端对端测试哪些是单元测试，有时候他们是混合起来的，不过只要记住我们的目标是保证功能可以正常运行救足够了。

按照软件工程自底而上的概念，前端测试一般分为单元测试（Unit Testing ）、集成测试（Integration Testing）和端到端测试（E2E Testing）。从下面的图可以看出，从底向上测试的复杂度将不断提高，另一方面测试的收益反而不断降低的。

关于软件测试分类，可见软件测试的分类

测试工具对比

在进行项目实践前，很重要的一项工作是选择合适的技术栈。好比在前端开发时应该选择 React，Vue 还是 Angular 作为框架一样，前端的测试工作也需要选择一套技术栈。很多时候大家在制定技术栈时容易走偏，在选择技术框架时不是选择最合适的框架，而是选择最热门的框架。当然一定程度上热门的框架能反应其受欢迎程度，可能是因为其出众的优点，如较高的开发效率、高效的渲染特性或者是活跃的社区。在前端开发中，很容易有这样的感受，就是只要半个月没有关注业界的最新动态，就感觉恍若隔世，新的解决方案层出不穷，让人喘不过气。

经过几年的前端洗礼之后，就已经过了慌乱的年纪，再也不会盲目地追寻新技术，而转向关注技术背后解决的痛点，原理等。

如何选择测试框架

测试框架基本上都做了一件事儿：

• 描述你要测试的东西
• 对其进行测试
• 判断是否符合预期

选择框架会考虑下面的点：

• 测试框架是否有简明的语法与文档。

  Mocha、Jasmine、Jest、AVA、Karma、Nightmare

• 断言(Assertions)：用于判断结果是否符合预期。有些框架需要单独的断言库。

  Should.js、chai、expect.js等等，断言库提供了很多语义化的方法来对值做各种各样的判断。当然也可以不用断言库，Node.js中也可以直接使用原生assert库。

• 适合 TDD / BDD：是否适合 测试驱动型 / 行为驱动型 的测试风格。

  BDD(Bebavior Driven Developement，行为驱动测试)和TDD(Testing Driven Developement，测试驱动开发)

  BDD和TDD均有各自的适用场景，BDD一般更偏向于系统功能和业务逻辑的自动化测试设计，而TDD在快速开发并测试功能模块的过程中则更加高效，以快速完成开发为目的。下面我们看下BDD和TDD具体的特点：

  BDD的特点：

  • 从业务逻辑的角度定义具体的输入与预期输出，以及可衡量的目标；
  • 尽可能覆盖所有的测试用例情况；
  • 描述一系列可执行的行为，根据业务的分析来定义预期输出。例如，expect, should, assert；
  • 设定关键的测试通过节点输出提示，便于测试人员理解；
  • 最大程度的交付出符合用户期望的产品，避免输出不一致带来的问题。

  TDD的特点：

  • 需求分析，快速编写对应的输入输出测试脚本；
  • 仅在自动测试失败时才编写新代码。
  • 重构去除不必要的依赖关系，然后重复测试，最终让程序符合所有要求。

• 异步测试：有些框架对异步测试支持良好。

• 使用的语言：大部分 js 测试框架使用 js。

• 用于特定目的：每个框架可能会擅长处理不同的问题。

  是要测试单个功能、单个组件、还是集成化测试？

  是要测试GUI逻辑、交互？

  是要测试非功能性指标？兼容性？

• 社区是否活跃。

测试工具的类型

测试工具可分为以下功能。有些只为我们提供了一种功能，有些功能为我们提供了一种组合。

为了实现最灵活的集合功能，通常使用多种工具的组合。

• 提供UI界面或者CLI工具：（Karma，Jasmine，Jest，TestCafe，Cypress）

  CLI工具会给出一系列测试，以及运行这些测试所需的各种配置和脚手架（运行什么浏览器，使用什么babel插件，如何格式化输出等）

• 提供测试框架（形成文件目录）：(Mocha, Jasmine, Jest, Cucumber, TestCafe, Cypress)

• 提供断言：（Chai，Jasmine，Jest，Unexpected，TestCafe，Cypress）

  断言函数检查测试返回的结果是否符合预期

• 生成，展示测试结果（Mocha，Jasmine，Jest，Karma，TestCafe，Cypress）

• 快照测试（Jest，Ava）

  快照测试(snapshot testing)，测试 UI 或数据结构是否和之前完全一致，通常 UI 测试不在单元测试中

• 提供仿真（Sinon，Jasmine，enzyme，Jest，testdouble）

  仿真(mocks, spies, and stubs)：获取方法的调用信息，模拟方法，模块，甚至服务器

• 生成测试覆盖率报告 (Istanbul, Jest, Blanket)

• 提供类浏览器环境(Nightwatch, Nightmare, Phantom, Puppeteer, TestCafe, Cypress)

• 可视化回归工具(Applitools, Percy, Wraith, WebdriverCSS)
  percy.io/), Wraith, WebdriverCSS)