作者：闲鱼技能——光酒
什么是单元测验
《单元测验的艺术》中对单元测验的界说：
一个单元测验是一段自动化的代码，这段代码调用被测验的工作单元，之后对这个单元的单个终究成果的某些假定进行校验。
单元测验简直都是用单元测验结构编写的；只要产品代码不产生改变，单元测验的成果是安稳的。
为什么需求单元测验
在我看来，单元测验的意义能够总结如下三点：
-
单元测验是确保你写的代码是你想要的成果的最有用办法
-
单元测验帮咱们刻画规划
-
单元测验是最好的文档之一
单元测验描绘了代码的预期行为，能够最有用地确保代码正确运转，减少代码缺陷；由于单元规划较小，当因为代码改变出现问题的时分，能够协助咱们快速定位问题；有单元测验掩盖的代码，让咱们更有信心，勇于定心做代码重构；
写单元测验的进程往往伴随着代码重构，假如发现一段代码单元测验很难写，就需求反思咱们的规划，进而重构促进代码规划的优化，协助咱们刻画规划；
同时单元测验也是一个最佳的、自动化的、可履行的文档；没有单测掩盖的代码，是很难被维护的。
什么是有用的单元测验
可读、可维护、可信任、快速履行！
《单元测验的艺术》中描绘优秀单元的特性：
它应该是自动化的，可重复履行；
它应该很简单完成；
它应该第二天还有意义；
任何人都应该能一键运转它；
它应该运转速度很快；
它的成果应该是安稳的（假如运转之间没有进行修正的话，多次运转一个测验应该总是
回来相同的成果）;
它应该能彻底操控被测验的单元；
它应该是彻底阻隔的（独立于其他测验的运转)；
假如它失利了，咱们应该很简单发现什么是等待的成果，进而定位问题所在。
可读性
“一般程序员写得出计算机能读懂的代码。优秀程序员写得出人能读懂的代码” — 马丁福勒
可读的代码才是可维护的；难以阅览和了解的测验用例，终究的成果便是删掉它，因为维护本钱过高。可读性高于纯粹的功能。
可维护性
团队内运用一套范式的结构，有助于使之更好用，快速定位问题；消除代码中的坏滋味。
可信任
可信任的意义：
-
测验可重复；
-
测验与依靠环境阻隔；
-
只测验不进行验证是不行靠的测验；
-
在测验类中不要依靠与测验的次序；
-
测验的成果是精准的：校验的精准以及过错问题的精准定位；
快速履行
确保单测快速履行，缩短反馈时长；
为什么有用的单元测验如此重要
无效的单元测验是没有意义的，反而会添加维护本钱，终究导致单元测验的失利！
如上图所示，坐标中恣意一个点，其与横纵坐标垂直线所形成的矩形面积代表CI为团队带来的价值，那么在我看来有两个要害的要素：横坐标是单元测验的根底才能建造，纵坐标则是有用的单元测验；
没有有用的单元测验，根底才能做出花来也毫无意义！完善的根底才能同时也协助咱们更低本钱的写出有用的单元测验。
怎么写有用的单元测验
咱们以Flutter为例，来一同评论怎么写有用的单元测验；
运用测验结构
Flutter官方供给的测验结构：
-
flutter_test
-
integration_test
**一致的编码约好
**
不论是AAA（Arrange-Act-Assert）还是GWT（Given-When-Then），一致的编码约好协助确保测验代码的可读性、可维护性。
运用测验替身
测验替身协助咱们阻隔被测验代码，加快履行速度，确保测验代码是可信任的；
-
Dummy：一种什么也不做的完成办法。接口中的每个办法什么也不做，假如办法有回来值，回来的值尽量接近null或许0。
-
Stub：Dummy的一种，Stub的函数并不回来null或0，而是回来能推进函数沿预定途径被测验的值。
-
Spy：Stub的一种，它回来测验所需的特定值，推进体系沿着咱们期望的途径前行。但是，Spy能记住对它所做的事，并答应测验问询。
-
Mock：Spy的一种，它回来测验所需的特定值，推进体系沿着咱们期望的途径前行，而且还会记住对它所做的事。不过，Mock还知道咱们的预期，根据这些预期，判别测验是否经过；换而言之，Mock中写明晰测验断语。
-
Fake：Fake是一种模仿器，它完成根底业务规则，这样测验就能要求该Fake按需求的途径履行。
**一个测验应当只检查一件事
**
清晰测验意图，一旦犯错能够精准定位问题；
一个测验只有一个模仿目标
防止过多模仿目标，一个测验用例的校验内容尽量简单；
防止冗余测验
冗余测验会进步维护本钱；
防止条件逻辑
条件逻辑会让你的单元测验更难以维护，出问题不简单排查，不行精准；
单测需求确定性
防止软弱测验，Mock不确定的依靠：时刻、随机数、并发性、根底设施、现存数据、耐久化、网络等等；
**测验快速履行
**
防止sleep等操作，导致测验履行缓慢；
防止过度指定
关于过度指定的评论，其核心问题便是要咱们判别哪些是单元测验应该掩盖的，哪些是应该留给其他测验手段的。假如一个场景，单元测验掩盖之后，导致常常单测失利，需求不断更新维护，那就能够考虑不做单元测验掩盖。
像素完美是一个典型的、常常拿出来评论的比如，Flutter的Golden Test便是一个golden master testing的比如；《有用的单元测验》中关于像素完美的评论：
像素完美：顾名思义，是一种特定于图形和图像生成的测验坏滋味。它混杂了魔法数字和根本断语，使得测验极难阅览也极端软弱。
这种测验简直无法阅览，因为即便测验在语义上是处于高层概念的，却仍然会针对硬编码的底层细节例如像素坐标和色彩来进行断语。指定坐标上的像素是黑还是白，与两个图形是否相连或堆叠的概念是有差异的。
这种测验极端软弱，因为即便很小的和不相关的输入改变——是否是另一个图像，或图形目标的烘托办法——都足以影响输出、打破测验，谁让你非要精确地检查像素坐标和色彩呢。相同的问题在采用golden master技能时也会遇到，其做法是事先将图像录制下来，并手工检查其正确性，今后再进行测验时就将烘托出的图像与之进行比对。
这些可不是咱们乐意去维护的测验。咱们不希望带着这种软弱的精确度去编写测验，而是运用模糊匹配和智能算法来代替繁琐的数值比较。
关于特定场景，Golden Test是一个十分有用的手段，但需求十分谨慎的评估；慎用Golden Test！
不要写永不失利的测验，不要写没有校验的测验
单测需求对清晰的逻辑校验，永不失利的测验或许没有校验的测验是不行信任的。
测验不要名不虚传
防止测验的描绘与测验内容不符；测验成果有必要精准；测验该失利的时分必定要失利！
测验私有或许受维护的办法
处理思路：
-
将办法变成公共办法；
-
将办法抽取到新类；
-
将办法变成静态办法；
-
将办法成为测验可见办法；
防止强制的测验次序
依靠测验次序导致测验可靠性变得软弱，未来维护本钱变高；
清理测验环境
在teardown阶段清理测验环境，例如复原全局的Config、清理创立的文件目录等等；
一致的单测命名、变量命名
一致的单测命名能够进步可读性、可维护性；
运用有意义的断语
断语的过错信息要有意义，出现问题能够清晰过错的原因；
把单元测验视为“一等公民”
测验用例应该被视为“一等公民”：相同需求代码评定，相同需求代码质量检查，确保单元测验的有用性；
单元测验代码评定的进程，也是团队同学互相学习的进程，沉积最佳实践的进程。
加快履行速度
日常对单测履行时刻进行监控，对测验进行功能剖析，优化履行时刻过长的测验用例。
测验金字塔
测验金字塔是Mike Cohn在他的著作《Succeeding with Agile》一书中提出了这个概念。测验金字塔是一个比喻，它告知咱们要把软件测验依照不同粒度来分组。它也告知咱们每个组应该有多少测验。
为了维持金字塔形状，一个健康、快速、可维护的测验组合应该是这样的：写许多小而快的单元测验。恰当写一些更粗粒度的测验，写很少高层次的端到端测验。留意不要让你的测验变成冰淇淋或许沙漏那姿态，这对维护来说将是一个噩梦，而且跑一遍也需求太多时刻。
防止测验重复
在完成测验金字塔时，你也应该牢记这两条根本规律：
-
假如一个更高层级的测验发现了一个过错，而且底层测验全都经过了，那么你应该写一个低层级测验去掩盖这个过错；
-
竭尽所能把测验往金字塔基层赶；
假如你已经在低层级测验里掩盖了一切状况，那么再维护一个高层级的测验就没有必要了。警觉淹没本钱的思维陷阱，决断摁下删除键。没有理由在不再供给价值的测验上糟蹋宝贵时刻。
弥补单元测验应该从哪里开端
单元测验应该及时编写，就算没有实践TDD，也应该在代码完成之后尽快编写单元测验，防止写出不行测验的代码，也能够让bug尽早露出；
但很不幸的，咱们许多时分在刚开端杰出工程，推行单元测验的时分，不得不面对弥补单元测验的状况；这绝对是一个有应战的工作。
弥补单元测验应该从哪里开端？参阅测验金字塔，关于根底组件库来说，能够根据具体状况来定；
关于业务库来说，第一步建议从金字塔顶端的测验：
-
优先掩盖回归测验用例中P0级别的用例；
-
防止过度指定的端到端测验；
-
恰当的契约测验；
接下来，从金字塔中间层开端，不断向上、向下弥补；
可测验的规划
应当简单、快速地为一段代码编写单元测验；可测验的规划，使咱们写出模块化的规划；
行动指南
为了写出可测验的代码，需求留意以下几点：
-
防止杂乱的私有办法；
-
防止final办法；
-
防止static办法；
-
运用new要当心；
-
防止结构函数中包括逻辑；
-
防止单例；
-
组合优于承继；
-
防止服务查找；
-
根据接口的规划；
可测验的代码是否违反了SOLID中的开闭准则？
可测验的代码规划，有的时分需求防止杂乱的私有办法或许受维护的办法，因为这些意味着不行测验；
这样的话是不是意味着可测验的规划违反了开闭准则呢？
在代码重构的时分，能够认为给目标模型添加了别的一种终究用户——测验用户。
别的假如一部分代码实在不希望露出，也能够运用@visibleForTesting 润饰；
单元测验与重构
写单元测验的进程往往伴随着重构；代码重构相同需求单元测验确保代码正确运转。
重构需求恪守的纪律：无测验重构无意义，频频重构、决断重构、坚决重构；
持续重构
将费事摧残在摇篮；
决断重构
灵敏编程的名言之一。规则很简单：重构时要英勇。英勇测验，英勇修正，不必害怕代码。
让测验始终能经过
建一个绿色安全区，不答应破窗出现。
留条出路
库房打好tag，以便在需求的时分能够回滚。
可测验的代码
可测验的代码便是解耦了的代码；可测验的代码协助咱们完成更好的抽象。
做不到TDD，能够做到测验先行
下图是遵从TDD三大规律的实践进程；TDD很强大，但不必定适用一切的团队，推行难度很大，学习曲线很高。
TDD事实上由两个方面组成：测验先行，以及演进式规划；测验先行是十分重要的工程实践，做不到TDD，能够做到测验先行。
在Kent Beck的经典名著《解析极限编程》中，说到：尽早测验，常常测验，自动测验！
测验先行的实质才能要求是接口的规划才能——能否清晰的界说出规划单元的鸿沟。
怎么了解单元测验代码掩盖率
不要把它们变成管理的目标。
这便是你运用掩盖率数字的目的：运用它们作为衡量标准来协助你改进，而不是用它们作为赏罚团队和使构建失利的棍棒。 ——《匠艺整齐之道》
代码掩盖率的一大忌讳：为了寻求代码掩盖率，只测验不进行验证；
一味寻求代码掩盖率，往往写出无效的单元测验，额外添加了维护本钱，终究不得不放弃以失利告终。
与其寻求代码掩盖率，不如将要点重视在确保写出有意义的测验。
沉积最佳实践
有必要供认单元测验有必定的本钱，本钱曲线来看，前期比较高；恰恰是这前期的门槛，让许多人望而生畏。在团队内推行的时分，最难的便是写出第一个单元测验；
咱们需求沉积最佳实践，协助下降写单元测验的本钱，让咱们更简单地写出有用的单元测验。
我觉得沉积最佳实践最好的办法，便是Code Review；正如咱们前面所说的，要把单元测验当成是“必定公民”，在Code Review的进程中，互相学习、分享最佳实践，消除无效的单元测验。
阻隔单元测验与集成测验
集成测验是对一个工作单元进行的测验，这个测验对被测验的工作单元没有彻底的操控，并运用该工作单元一个或多个真实依靠，例如时刻、网络、数据库、线程或随机数生成器等。
任何测验，假如它的运转速度不快，成果不安稳，或许要用到被测验单元的一个或多个真实依靠，便是集成测验。
在日常开发进程，咱们需求建一个绿色安全区：单元测验与集成测验阻隔；
集成测验不行安稳，运转时刻长等问题，假如不做阻隔，日常开发糟蹋时刻和精力维护，最终导致开发人员不再信任测验。
单元测验与ABTest
单元测验与ABTest有什么关系吗？事实上没有什么关系。但必定程度程度上，它们实质是相同的，都是保证线上代码质量（当然单测的本钱，关于基建、开发者的才能的要求更高）；
在日常开发中，常常自动为新的代码逻辑添加AB开关，一旦线上出问题留一条后路；产生问题的时分往往慨叹AB开关救我一命；
单元测验能够让问题左移，防止问题上线，相同是一道维护；
假如有一天团队同学乐意自动添加单元测验来维护自己的代码，那么单元测验这件事就算比较成功了。
写在最终
从软件工程到杰出工程，单元测验从可选变成了必要；想要完成骨干开发、大库模式，单元测验是前提条件。
关于单元测验这件事，我觉得最重要永远是写单元测验的人，优秀的团队文明十分重要，没有什么能够真正衡量单元测验做的好坏，有的只是程序员的工作操守。
咱们花了很大的篇幅评论有用单元测验的重要性以及怎么写出有用的单元测验，不得不供认单元测验有必定的本钱，真正实践依然需求许多的路要走，需求咱们在实践中界说好单元测验的鸿沟，找到最适合团队的最佳实践。
参阅文档
-
《单元测验的艺术》
-
《有用的单元测验》
-
《Succeeding with Agile》
-
《匠艺整齐之道》
-
The Test Pyramid：martinfowler.com/articles/pr…
-
Software Engineering at Google：qiangmzsx.github.io/Software-En…
