最近部门开始做单元测试，我作为探路者先行摸索，经过一段时间的摸索，感觉还是颇有收获，下面整理一波!
1. 什么是单元测试？
单元测试（unit testing），软件中的最小可测试单元进行检查和验证。代码以单元为单位进行测试。它可以是一个函数、一个模块、一个包或者一个类，甚至是一个对象。在 JavaScript 中，通常是以类或者模块作为一个单元。
2. 为什么要接入单元测试，单元测试有什么魔力？
-
开发质量的提升。将测试前置，从而可以越早发现问题，提高效率，降低成本。
确实可以在写单元测试发现一些代码问题，同时为了更好的通过单元测试，会去优化一下代码。 -
优化设计。编写单元测试将使用户从调用者的角度观察、思考，特别是使用TDD驱动开发的开发方式，会让使用者把程序设计成易于调用和可测试，并且解除软件中的耦合。
TDD可不是一件容易的事，刚入门比较难，大佬忽略不计。 -
便于后期重构。单元测试可以为代码的重构提供保障，在完整、有效的单元测试覆盖率的基础上，只要重构代码之后单元测试全部运行通过，那么在很大程度上表示这次重构没有引入新的BUG。
没有尝试，应该是可以吧！ -
文档记录。单元测试就是一种无价的文档，它是展示函数或类如何使用的最佳文档，这份文档是可编译、可运行的、并且它保持最新，永远与代码同步。
也是待考证，渣渣单元测试可能没这个功能吧！ -
具有回归性。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地地快速运行测试，而不是将代码部署到设备之后，然后再手动地覆盖各种执行路径，这样的行为效率低下，浪费时间。
这个倒是真的。
3. 单元测试可以带来的问题。
-
会占用一定的开发成本，增加开发工作量。
不得不说，单元测试真是比代码难写很多，什么叫一天写代码，三天写单元测试，真的是有可能的。 -
旧项目加入单元测试改动很大，会有一定的风险。
旧项目如果涉及不合理，结构不单元，想写好单元测试太难，这就需要改动，但是改动又可能造成新的问题，想好方案再加入单元测试吧！ -
会有一定的学习成本，对开发者要求比较高。
是有学习成本，我能说我学了好几个月吗，了解底层才能写出好的单元测试。
4. 单元测试有哪些模型？
-
TDD（Test Driven Development）：测试驱动开发，先写测试代码，之后编写能通过测试的业务代码，可以不断的在能通过测试的情况下重构。
TDD试了一下，还是不容易，网上视频课的例子看起来很容易，但是实操项目里的还真不易。 -
BDD（Behivior Driven Development）：行为驱动开发，与 TDD 很相似，测试代码的风格是预期结果，更关注功能，看起来像需求文档。
BDD没试过，这个不好说了。
5. 单元测试框架
框架：提供整个测试环境，包括except，assert语法，mock模块，代码覆盖率。
| 框架名称 | Jest | Mocha | Jasmine |
|---|---|---|---|
| star | 35.3K | 20.5K | 15.1K |
| Fork | 5.1K | 2.8K | 2.2K |
| 特点 | 零配置，开箱即用 | 灵活，可扩展 | 零配置，开箱即用 |
| 支持断言（assert） | 支持 | 可配置(引入chai) | 支持 |
| 支持仿真(mock) | 支持 | 可配置 | 支持 |
| 模拟函数(spies) | 支持 | 可配置 | 支持 |
| 支持快照(Snapshot) | 支持 | 可配置 | 可配置 |
| 测试进程 | 隔离并行测试 | 全局 | 全局 |
| 测试覆盖率报告 | 无需配置 | 需配置 | 无需配置 |
| 运行环境 | node环境 | node以及浏览器环境 | node环境 |
注：star 数据来源于2021-04-07
- Jest facebook坐庄，基于Jasmine，开箱即用，对react 项目友好，适合大型项-目并行测试，效率高。
- Mocha 使用人最多，高扩展性， 但需要较多的配置。
- Jasmine 开箱即用，测试兼容你选择的所有框架或库，但对异步测试兼容弱，全局。
没有尝试，难以体会Jest的开箱即用，以上三种框架我都试了一下，果然还是Jest最便捷，基本不需要怎么配置，就能顺利进行基本单元测试，体验特别丝滑。
好啦，以上就是关于单元测试的一些基本东西啦，下一节将会说说Jest的一些东西。
