前端单元测试初识

最近部门开始做单元测试，我作为探路者先行摸索，经过一段时间的摸索，感觉还是颇有收获，下面整理一波!

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模块，代码覆盖率。

注：star 数据来源于2021-04-07

• Jest facebook坐庄，基于Jasmine，开箱即用，对react 项目友好，适合大型项-目并行测试，效率高。
• Mocha 使用人最多，高扩展性， 但需要较多的配置。
• Jasmine 开箱即用，测试兼容你选择的所有框架或库，但对异步测试兼容弱，全局。

没有尝试，难以体会Jest的开箱即用，以上三种框架我都试了一下，果然还是Jest最便捷，基本不需要怎么配置，就能顺利进行基本单元测试，体验特别丝滑。

好啦，以上就是关于单元测试的一些基本东西啦，下一节将会说说Jest的一些东西。