有一段时间，程序员获得的报酬直接与他们编写的代码行数挂钩。他们被视为工作在小隔间里的源代码生产机器，这导致他们仅将编程视为一天八小时的工作，做完之后一段时间就将其遗忘。
但时代变了。大部分的小隔间工作场所消失了，程序员开始爱上他们的工作。随着敏捷技术和软件工艺运动的出现，许多对程序员和编程有用的新工具随之出现。TDD正逐渐成为代码编写的实际方式，甚至向隔间世界最幽暗角落的程序员揭露了SCRUM和Kanban的秘密。
自动测试和测试驱动开发（TDD）是敏捷给我们程序员提供了一些关键技术。本文的主题是使用实现这些技术的工具产生测试代码覆盖。
“在计算机科学中，代码覆盖是一种度量，用来描述程序源代码经过特定测试套件测试的程度。”~
上述定义，摘自，是描述代码覆盖含义的一种最简单方式。从根本上说，你的工程中包含大量产品代码，也有很多测试代码。测试代码执行产品代码，测试覆盖意味着你的产品代码有多少经过测试。
信息可以通过各种方式呈现，从简单的百分比到直观的图表，甚至在你最喜欢的集成开发中实时高亮显示。
获取覆盖数据的一种方法是在CLI（命令行接口）中执行测试，分析输出。对于这个例子，假设我们使用的是类UNIX系统（Linux，MacOS、FreeBSD等）。Windows用户需要稍微调整径和可执行文件的名称，但应该相当类似。
让我们打开控制台程序，切换到测试文件夹目录下。然后，选择生成纯文本覆盖数据选项，运行phpunit程序。
phpunit --coverage-text=./coverage.txt ./WordWrapTest.php
如果你的代码只能通过SHH或者网络访问远程服务器并在编译，前面的例子很有趣，也非常有用。但是，如果所有这些信息都在你的集成开发中是不是更棒？
如果你使用PHPStorm，一切都会在单击的过程中完成！选择执行覆盖测试，所有信息神奇般地立刻呈现。
覆盖信息将在你的集成开发的许多地方以不同的方式呈现：
这个强大的工具同时到达程序员和管理者手中，不可避免会出现一些。在程序员按照编写的代码行数获得酬劳或者管理者意识到实现一个系统非常简单之后，一些人开始按照代码覆盖率给程序员发放酬劳。代码覆盖越高意味着程序员越小心，对吗？这是一个。代码覆盖不是编写代码质量的度量。
有时程序员倾向于认为100%覆盖的代码没有bug。这是另一个。代码覆盖仅仅是告诉你你已经测试过每一行代码。代码覆盖是已执行代码行数的度量。它不是正确实现代码行数的度量。例如，写了一半的算法，使用定义一半的测试将会得到100%覆盖率。但这并不意味着该算法已完成或是能正常工作。
最后，实现系统非常容易。当然，如果你使用TDD，你自然会有很高的代码覆盖值。对整个工程而言，100%覆盖是不可能的。但是对于小的模块或类，获取100%的覆盖非常容易。就拿我们的源代码来说，假设你没有进行任何测试。执行所有代码的最简单测试是什么？
function testItCanWrap() { $w = new WordWrap(); $this-assertEquals(a bnc, $w-wrap(a b c, 3)); $this-assertEquals(anb, $w-wrap(a bc d, 3));}
代码覆盖是一种状态器，而不是衡量性能或正确性的单元。
代码覆盖率是给程序员参考的，而不是给管理者参考的。它是我们发现代码中问题的方法。该方法可以发现过时的，未测试的类。还可以发现未经测试执行可能导致问题的径。
在实际项目中，代码覆盖率总是低于100%。取得完全覆盖是不可能的，如果取得，那也常罕见的。然而，为了获取98%的覆盖率，你必须将目标定在100%。其它任何目标都没有意义。
下面是Syneto的StorageOS配置程序的代码覆盖率。
整体覆盖率大约只有35%，但结果需要说明一下。大部分模块都处于绿色状态，超过70%的覆盖率。然而只有一个文件夹，Vmware，降低了整体平均值。这模块中有很多的类，类中只定义了通信API。那些类没有测试的必要。它们是由可靠代码自动生成。程序员知道这些代码，他们也知道如何解释结果。管理者可能会测试，因为代码显示为红色状态，这对于不了解程序内部细节的人来说很可疑。测试这部分代码有意义吗？一点也没有！这将是一个无用的测试，除了占用几十秒宝贵的编译时间没有任何的优势。
这就是我们所说的代码覆盖：对程序员来说，它是一个很棒的工具，可以高亮显示可能出现问题的信息源，对大部分管理者来说说却是被曲解的事实，成为和度量程序员行为的工具。正如使用的其他工具一样，代码覆盖正确使用很简单，但也容易误用。
分享这篇文章：
网友评论 ()条 查看