单元测试-认知篇

前言

Hi，各位，好久不见，甚是想念。

总算是安顿下来了～

引子

单元测试是什么？

市面上的单元测试泡影以及相关资料基本都停留在：

• 什么是单元测试？
• 怎么去做单元测试？

然而，并没有所谓的：

• 为什么要做单元测试？
• 单元测试最佳实践
• …

其实上面的然而也并非是绝对的，还是有一些比较优秀的文章集合，像：

React 单元测试策略及落地

• 微信内链接：https://www.infoq.cn/article/asmlfdi3pi_vepxpo3lu

React 单元测试策略及落地

• 微信内链接：https://github.com/linesh-simplicity/linesh-simplicity.github.io/issues/200

且不考虑测试代码的好坏与优劣，单纯针对单元测试，对于不同的测试case而言。

需要去不断的领悟测试技能，测试方案与测试方法，尝试形成自己的测试风格与规则规范。

笔者是从去年下半年开始接触单元测试的，从一开始的邯郸学步到形成一套相对成熟的测试方案。

一定要戒骄戒躁。

为什么要做单元测试？

其实，大家在开发流程（我这里指的是比较完备的开发流程下）下工作的时候，会经常性的出现qa与dev的各种撕逼，怼人的情节，但是即便是不出现，也会新增一些沟通 -> 复现 -> 流程上的成本消耗。

以上是其一，其二而言的话，考虑整个技术团队的流动性会比较高，一些复杂的代码块，功能模块肯定会让后来的人难以理解，即便是理解了，也很难动手去重构优化，重构优化的前提的，理解所有代码的运转以及功能需求。

当然，上面说的也仅仅是两个主观因素罢了，还有一些暂时就不一一列举了。

单元测试最佳实践

这一部分会在后面的文章中持续输出～