尤小右言测试
据某『前辈』自己说，他因为时间不够，所以是放弃写测试的。为什么时间不够呢，因为工具落后，开发效率太低呗。而且用古老的比如 Qunit / YUI test 写的测试，必须手动打开一个一个浏览器测，也没有代码覆盖率信息。现在呢，代码规范有ESLint，单元测试有 Karma，集成测试有 CasperJS/Nightwatch，代码覆盖率用 istanbul，配置完毕后一行命令自动多浏览器测试汇报结果和覆盖率，如果搭好持续集成环境，甚至不用你自己手动跑，push 到仓库就行了。这些东西也不需要团队人人都懂，架构师搭好底子，新人只要用就行了，但是却可以大幅提高整体的代码质量。 - 尤小右
编写可测试的JS
- 什么是可测试的代码，
- 短小但不太复杂的代码、完整的注释，以及松耦合。
- 扇入：如果同样的代码发现编写了2遍，那么是时候将其提取到函数中了。
- 测试框架，基于行为驱动开发BDD框架Vows
- 单元测试只对被测试的代码块进行测试编写。
- 服务器端单元测试：Jasmine和Mockery npm包
- 边界测试
- 其它测试：集成测试、性能测试和负载测试
- 集成测试框架：Selenium IDE是一个Web browser autoMation
- 性能测试 Jmeter
编写可维护的JS
- 讲配置文件抽离出来
- 抛出自定义错误 try-catch throw error
- 自动化文档 JSDOC
- JavaScript polyfills（也称为 shims）
测试分类
测试因粒度不同又可以分为单元测试、接口测试、功能测试
在 WEB 领域，功能测试亦称为端到端测试（End to End Test，简称 E2E 测试）
前端测试的部分
- 一是 Utils，包括一些格式化的工具函数
- 二是 Service 里的 Model 状态
- 验证什么？CRUD
- 三是 View 状态，这些和具体展现以及业务逻辑都有关，是比较复杂的部分
优先级 - 有选择的写测试
首先，测试比较重要的部分，评估一些风险。比如数据统计、计费等和用户密切相关的内容。
其次是测试比较稳定的部分，即跟业务不相关的部分函数。
再次是测试依赖比较少的部分，这里只需要关注它整个逻辑本身
冒烟、回归、全量
冒烟测试
冒烟测试是硬件测试的概念，流传过来的。
冒烟一般是做验证，主要关注点在核心功能和常用功能上面（比如用户注册、支付等）
冒烟用例一般都是比较重要的功能的测试用例了，如果不是比较大范围的改动，回归的时候就回归冒烟测试用例就好。
回归测试
新版本上线之前，对整个产品的系统模块做一次全面的测试，相当于一次全身检查
这个全面是相对的，因为由于时间和人力成本的关系不可能做到覆盖率百分百，只能对各个模块的主要功能，易错点进行测试
全量测试
?> 针对具体的功能点进行测试
要做的是对需求进行分析解疑，设计测试点
基本上每个细节都需要测到，可以理解为对身体的某个器官进行深入详细的检查。
传统的软件测试与自动化测试
传统的软件测试过于依赖手工操作：首先将应用程序部署到测试环境，然后执行一些黑盒测试，例如，通过点击用户界面来查看一切是否工作如常。
通常这些测试将由测试文档指定，以确保测试人员每次测试的内容是一致的。
自动化测试
如果你正在践行持续集成或者持续交付的实践，那么你会有一条部署流水线来在每一次提交改动时运行自动化测试。
通常这个流水线会被分成几个阶段，它们会逐步建立起让你把软件部署到生产环境的自信。
Commit -> test -> pre deploy
测试金字塔
要点
- [ ] 写许多小而快的单元测试。
- [ ] 适当写一些更粗粒度的测试
- [ ] 写很少高层次的端到端测试
- [ ] 竭尽所能把测试往金字塔下层赶
集成测试
- 测试的是应用与所有外部依赖的集成。
- 和一些外部环境做集成（数据库，文件系统，向其他应用发起网络请求）
- 尽可能在本地运行外部依赖，如启动一个本地的 MySQL 数据库
- 如果是与外部服务集成，可以在本地运行该服务的实例，或构建一个模拟真实服务的假服务
UI 测试与 E2E 测试
测试用户界面的行为非常简单。点击一下，输入数据，然后看到用户界面状态如实变更。
对于传统的网页应用，UI 测试可以用 Selenium/headless chrome 这一类工具完成
现代前端框架的项目，通常会提供一些工具和组件，帮你从很低的测试层级（单元测试）对界面交互进行测试。
对于更传统一些的服务端渲染应用，使用 Selenium 会是最佳的选择。
关系
- 测试用户界面不必非得通过端到端的方式完成。
- 你只需要为前端的 JavaScript 代码写一些单元测试，同时用桩将后端隔离开即可。
E2E 测试
要点
因其高昂的维护成本，你应该尽量将端到端测试的数量减少到最低限度。
重要的用户旅程
找出一两个重要的用户旅程，并将其用端到端测试来覆盖。但到此为止，再多的测试就会开始带来痛苦了。
举例来说，假设你正在构建一个电子商务网站，最具价值的顾客旅程可能是这样的：用户搜索一件商品、将其加入购物车，然后付款。就这么简单。只要这个旅程正常工作，你应该无需过多担心。
!> 谨记：在测试金字塔里，有很多更低层级的测试，这些测试已经全面测试了各种边缘情况及与其他系统的集成。不需要再在高层级测试里重复测一遍。否则，高维护成本和一堆谎报错误将会降低开发速度，迟早会让你对测试失去信心。