单元测试 - 是对软件中的最小可测试单元进行检查和验证：API，函数。
测试用例 - 是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或合适是否满足某个特定需求
输入 -> 执行条件 -> 预期结果
TDD
- 测试驱动开发（Test-Driven Development），通过测试用例指引实际的开发，让开发首先站在全局的视角来看待需求
- 从实现的角度
- 需求分析 -> 编写单元测试 -> 编写代码使单元测试全部通过 -> 重构并重复测试
BDD
- 行为驱动开发（Behavior Drivern Development），
- 基于行为，更自然，前端开发更倾向于BDD
- 从业务角度定义具体可衡量的目标 -> 找到可实现目标的方法 -> 编写单元测试 -> 实现行为 -> 检验产品运行结果是否符合预期
单元测试技术
- 测试框架
- 断言库
- mock 库
- test runner 执行环境
- 覆盖率工具
|
- 测试框架 - Qunit - jasmine - jest - mocha - intern |
- 断言库 - chai - should - expect - assert - 检查结果 - 提供了一套API， 帮助开发者在单元测试的过程中， 判断某个值是否符合预期 |
- mock库 - sinon - 解决数据和外部依赖部分 不能控制、实现成本较高、操作危险等
|
- test runner - karma - buster.js -提供执行环境，管理执行流程， 有了执行环境 可以实现单元测试的自动化执行， 而不需要手动点开浏览器去执行， 也是单元测试可以成为重构 系统升级的一个基础 |
- 覆盖率工具 - Istanbul - 帮助我们衡量单元测试的有效性 |
|
- 好的单元测试： - 可靠性 - 可维护性 - 可读性 |
- 编写可靠的测试： - 及时修改和维护 - 避免测试中逻辑过多 - 只测试单一的点 - code review - 独立运行 - 充分考虑边界条件 - 模拟数据尽量贴近真实 |
- 编写可维护的测试： - 测试公有方法，私有方法变更和调用频繁 - 移除重复代码 - 保证setup方法的可维护 - 测试隔离，不允许互相依赖 - 单个测试中避免多个断言 |
- 编写可读的测试： - 命名的问题 - 有意义的断言 - 断言与操作分离 |
- 覆盖率： - 行覆盖率 - 函数覆盖率 - 分支覆盖率 - 语句覆盖率 |
- 测试用例分类： - 数据层 - 逻辑层 - 工具类 - 展示层 |
推荐书籍：软件测试、单元测试的艺术、修改代码的艺术、重构改善既有代码的设计