Jest单测
单元测试
来自维基百科的定义：
在计算机编程中，单元测试（Unit Testing）又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。 程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
定义里面指出，单元测试针对的是程序的最小单元，因此我们应该针对最小单元来写单测。
现状与问题
-
缺乏意识：没有单测意识，很多代码没有单测
-
缺乏设计：模块缺乏设计，相互耦合，写单测困难
-
测试困难：升级公共 API，人工测试验证困难
-
测试不全面：部分代码分支众多，人工测试没办法覆盖所有分支
单测的价值与意义
-
能力建设：一个具备开发经验的开发人员，基本上都会编写单元测试。即便不会，可以通过培训来快速达成。从学习曲线上看，单元测试很容易上手。
-
提升效率：能够通过 mock 数据，及早发现问题，而越早发现Bug，造成的浪费就会越小。
-
追求卓越：单元测试可以充当一个设计工具，它有助于开发人员去思考代码结构的设计，让代码更加有利于测试。
-
测试更全面：能够覆盖 QA 测试覆盖不到的情况，比如各种 if 分支、异常处理。
-
更有信心：升级公共 API 时，如果依赖这个 API 的所有代码单测都能通过，那我们对这次代码升级是更有信心的。
单测和自动化的关系
在公司部署考QC的时候，就尝试过部署自动化流水线。
单元测试的「透镜」是什么呢？一言以蔽之，两点：反馈速度和自动化。
人员会流动，应用会变大。人员一定会流动，需求一定会增加，直至再也没有一个人能够了解应用的所有功能，那时对应用做出修改的成本将变得很高。因此，意图依赖人、依赖手工的方式来应对响应力的挑战首先是低效的，从时间维度上来讲也是不可能的。因此，为了服务于“高响应力”这个目标，随时重构整理代码是必须的，这就需要我们有一套自动化的测试套件，它能帮我们提供快速反馈，做质量的守卫者。唯解决了人工、质量的这一环，开发效率才能稳步提升，团队和企业的高响应力才可能达到。
单测框架Jest
-
Fast 天下武功，唯快不破。确实很快。
-
Opinionated 不需要你做出选择和配置，就能提供所有的东西，比如 Mock（干掉 Sinon）、Test Runner（干掉 Karma）、Matcher（干掉 Chai）、Test Coverage（内置 istanbul）
-
Watch Mode 守护模式。非常注重开发者体验，能够在编码的时候帮助我们快速获得测试结果的反馈。
-
Snapshot Testing 快照测试。
Jest基本操作
-
安装
npm install --save-dev jest -
待测试函数sum。(node使用Common JS方式导出)
function sum(a, b) {
return a + b;
}
module.exports = sum; -
sum.test.js
const sum = require('./sum');
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
Given/When/Then 的套路
麻雀虽小五脏俱全，在上面的例子当中，我们可以看到很多的测试元素，下面将会一一介绍：
Given When Then 的经典格式，我们常常称之为测试三部曲，也可以解释为 3A 即：
| GWT | 3A | 说明 |
|---|---|---|
| Given | Arrange | 准备测试测试数据，有时可以抽取到 beforeEach |
| When | Act | 采取行动，一般来说就是调用相应的模块执行对应的函数或方法 |
| Then | Assert | 断言，这时需要借助的就是 Matchers 的能力，Jest 还可以扩展自己的 Matcher |
在 expect 后面的 toBe称之为
expect(1 + 1).toBe(2)
expect(1 + 1).not.toBe(3)
