背景

去年下半年，我在微信书架里加入了许多技术书籍，各种类别的都有，断断续续的读了一部分。

没有计划的阅读，收效甚微。

新年伊始，我准备尝试一下其他方式，比如阅读周。每月抽出1~2个非连续周，完整阅读一本书籍。

这个“玩法”虽然常见且板正，但是有效，已经坚持阅读十个月。

已读完书籍：《架构简洁之道》、《深入浅出的Node.js》、《你不知道的JavaScript（上卷）》、《你不知道的JavaScript（中卷）》、《你不知道的JavaScript（下卷）》、《数据结构与算法JavaScript描述》、《WebKit技术内幕》、《前端架构：从入门到微前端》、《秒懂算法：用常识解读数据结构与算法》、《JavaScript权威指南》、《JavaScript异步编程设计快速响应的网络应用》。

当前阅读周书籍：《编写可测试的JavaScript代码》。

覆盖率目标

一般来说，单元测试的覆盖率目标与集成测试的覆盖率目标不同。由于集成测试覆盖更大范围的代码，很难确定已覆盖代码和已测试代码之间的关系。单元测试只紧密关注某一段代码，如一个函数或一小块功能，而功能测试将覆盖更多的代码行。代码覆盖率和单元测试表现出完全相同的问题：一行代码被一个测试执行了，并不代表该代码被“测试过”了。

因此，一行代码被执行和一行代码被单元测试测试过这种本已脆弱的联系，在集成测试和代码覆盖率测试上显得更加明显。毕竟，测试的期望结果不是“代码覆盖率”，而是正确的代码。

当然，要相信自己的代码是正确的，该代码在测试时必须要被执行，并且能够按预期执行。通过测试简单地执行代码是不够的，但它却是有必要的。

所以，除了代码覆盖率还有什么？

比较理智做法是尽量让单元测试的代码覆盖率结果保持在80%。基于单元测试目的，功能测试并不重要，理想情况下，单元测试只测试一个函数或方法（除了知道哪个函数有与之相关联的任何测试）。而其他代码，尤其是单元测试方法中的初始化代码，只是顺便覆盖一下。单元测试应该覆盖至少80%的所测试功能。但是要注意如何达到这一水平，因为该数字并不是真正的目标。真正的目标是能够按预期和非预期方式运行的良好测试。代码覆盖率度量应该是良好测试的衍生结果，而不是相反结果！为获得更大的覆盖率而编写测试是很容易的，但没必要。幸运的是，专业开发人员永远都不会这么做。

对于集成测试，该测试在功能层面上的，代码覆盖率相对它们自身来说没有多大用途。代码覆盖率对阅读并理解一个功能的所有代码是非常有益的。通常我们会惊讶于哪个代码是否被执行——最初，这是很有趣的信息。但随着时间的推移，对功能测试来说，代码覆盖率度量就不太有意义了。然而，聚合所有功能测试的覆盖率信息却是非常有用的。事实上，对任何测试以及所有类型的测试，包括性能测试、集成测试、验收测试所聚合的覆盖率度量，对检查测试的彻底性来说都是很好的标准。

有多少百分比的代码在验收测试中被执行？集成测试呢？性能测试呢？这些百分比都是很有用的数字。有趣的是，与单元测试的行覆盖率相比，百分比数字好坏并没有标准。随着时间的推移，这些数字（行覆盖率）应该会增加，所以应该首先瞄准最常见的代码路径。要关注最常用功能的功能测试。当然，首先肯定想要更高的覆盖率。对于单元测试和功能测试，行覆盖率应该接近于100%，但请记住，代码覆盖率度量不是测试的最终目标。要在多种不同的条件下锤炼代码。不要本末倒置。

总结

代码覆盖率相关的知识到这里已经全部讲完了。下面我对这几篇代码覆盖率相关的文章做一个总结。

• 生成并查看代码覆盖率信息是单元测试的关键，并且对聚合集成测试也很重要。代码覆盖率数据并没有告诉我们所有信息，代码覆盖率信息提供了一个很好的单个数字，用于跟踪测试过程。
• 高百分比的代码覆盖率会产生误导，但是低百分比不会。不管是单元测试还是其他测试，你、你的老板以及别人一眼就能看出有多少代码已经被测试覆盖到了。低百分比的行覆盖率可以提供很明显的标识，以便让我们知道未来的测试工作重心在哪里。
• 从单元测试和集成测试中捕获代码覆盖率结果，并将其合并成为一个单一报告，相对来说是比较简单的。该报告提供了一个很方便的度量方法，用于跟踪测试进度。
• 除了静态代码分析，跟踪测试的代码覆盖率将会使我们从另外一个层面来分析代码。没有什么数字能够整体说明代码或测试的好坏，但随着时间的推移，收集和跟踪这些数据，可以让我们了解代码是如何发展的。
• 达到代码覆盖率目标肯定是良好测试的衍生结果，而不是目标本身。不要忘记为什么要编写这些测试：确保代码正确且健壮。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。