单元测试 #8
Description
单测定义
单元测试（Unit Test）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。一个单元是最小可测试部件，可以是单个模块、函数、类方法等。
- js 函数库
- koa, express 中间件
- redux action creator + reducer + middleware
单测地位：测试金字塔
传统的测试金字塔表明从上到下，测试用例越来越多，测试功能点越来越分散，测试成本越来越低。但是随着前端框架（react，angular，vue 等）的发展，UI 测试成本不像以前那么高。
单测意义
- 确保程序单元行为符合预期
- 覆盖边界条件
- 优化代码结构
- 利于重构代码
单测流程：测试驱动开发
单元代码和测试代码的开发流程可以参考测试驱动开发（Test Driven Development，TDD）思路。
测试驱动开发是一种软件开发方式，倡导先写测试程序，然后编码实现其功能。
Kent Beck：
“测试驱动开发不是一种测试技术。它是一种分析技术、设计技术，更是一种组织所有开发活动的技术”。
“代码简洁可用这句言简意赅的话，正是 TDD 所追求的目标“。
分析技术：明确需求，拆分任务。
设计技术：代码设计、重构、再设计。
组织所有开发活动技术：组织测试、开发和重构。
TDD - 分析需求：用户故事
TDD 可以通过用户故事来描述代码的功能。
用户故事（User Story）是指对系统功能的自然语言描述，它针对不同用户来描述系统功能，原本属于敏捷开发的概念。基本形式为：As a < type of user >, I want < some goal > so that < some reason >，即 who（谁）、what（做什么）、why（为什么）。
举例：
作为一个信息录入员（who），我想有个页面录入信息（what）以便审核员能够看到我录入的信息（why）。
作为一个审核员（who），我想有个页面能看到录入员录入的信息（what）以便我快速检查信息正确性（why）。
很多时候仅有 who、what、why 是不够的，还需要有 when 和 where，用户故事的模板的就可以改为：As <who> <when> <where>, I want <what> so that <why>。
举例：
作为一个信息录入员（who），当信息没有过审（when），在录入页面上（where）我想能看到审核失败原因（what），以便我能快速修正信息（why）。
作为一个审核员（who），当有新信息录入时（when），在审核页面上（where）我想能看到新信息录入的提示（what），以便我能快速检查新信息（why）。
- 梳理需求，明确目标
- 拆分功能，帮助理解
- 评估需求价值、优先级、研发周期
- 适合非开发人员如产品书写
对于单测而言，更关心 who、when、what。
| User Story | Unit Test |
|---|---|
| who | function、module、class method |
| when | input |
| what | output |
单测的用户故事基本格式为：For <function> when input <arguments>,then output <value>
然后根据编写的用户故事来明确单测的测试 case 和代码的功能。
TDD - 开发流程
TDD 开发流程：编写测试用例代码 ==> 执行测试用例 ==> 测试失败，新增或重构单元功能 ==> 重新执行测试用例 ==> 测试通过，新增或重构单元功能，如此往复。
单测局限
- 无法发现程序所有错误
- 难以养成测试驱动开发的习惯
- 增加额外开发成本