安装和配置PHPUnit 和 Xdebug 请参考我的另两篇博文:
https://blog.csdn.net/JineD/article/details/117670074 PHPUnit 安装指定版本及使用
https://blog.csdn.net/JineD/article/details/106967800 phpstorm配置xdebug进行远程调试
一、build code coverage report
有两种方法:
1.直接执行 phpunit 要执行的测试文件 --coverage-html ./tests/codeCoverage 命令
Error: No whitelist is configured, no code coverage will be generated.
解决办法:在当前目录下创建phpunit.xml 我的单元测试文件目录为当前文件夹的test目录下
<?xml version="1.0" encoding="UTF-8"?>
<phpunit bootstrap="vendor/autoload.php">
<filter>
<whitelist processUncoveredFilesFromWhitelist="true">
<directory>./test</directory>
</whitelist>
</filter>
</phpunit>
注意:以上配置如果没有配置好会出现如下错误,请检查是否写错,或路径错误
Error: Incorrect whitelist config, no code coverage will be generated.
如配置成功执行如下语句
phpunit test/ArtTest.php --coverage-html ./tests/codeCoverage
将codeCovertage中文件复制到本地,打开
2.在 phpunit.xml 添加如下代码:<phpunit></phpunit>中添加
<logging>
<log type="coverage-html" target="./test/codeCoverage" charset="UTF-8"/>
</logging>
然后直接执行 phpunit 即可。
phpunit test/ArtTest.php
完成会在 tests/codeCoverage 目录下生成 html 报告,如下所示:
二、想完成多个文件都进行代码覆盖率测试
直接执行 phpunit 会报
No tests executed!
在phpunit.xml文件中添加 执行目标文件夹
<testsuites>
<testsuite name="Application Test Suite">
<directory suffix="Test.php">./test</directory>
</testsuite>
</testsuites>
在项目根目录直接输入 phpunit
产生的html报告为
报告解析
行覆盖率(Line Coverage)
*行覆盖率(Line Coverage)*按单个可执行行是否已执行到进行计量。
函数与方法覆盖率(Function and Method Coverage)
*函数与方法覆盖率(Function and Method Coverage)
*按单个函数或方法是否已调用到进行计量。
仅当函数或方法的所有可执行行全部已覆盖时 PHP_CodeCoverage 才将其视为已覆盖。
类与特质覆盖率(Class and Trait Coverage)
*类与特质覆盖率(Class and Trait Coverage)
*按单个类或特质的所有方法是否全部已覆盖进行计量。
仅当一个类或性状的所有方法全部已覆盖时 PHP_CodeCoverage 才将其视为已覆盖。
通过这样的分析,完善单元测试,保证代码测试的完整性,也能让代码更加健壮。
三、代码覆盖率的意义在哪儿
一、基本概念
代码覆盖率是单元测试活动任务之一;
覆盖率分语句覆盖率(即通常所说的行覆盖率)和分支覆盖率。
二、价值
代码覆盖率的分析能在一定程度上评判代码质量,一般覆盖率高的代码出错的几率会相对低一些。但是高覆盖率只是表示执行了很多的代码,并不意味着这些代码被很好地执行了。所以,似乎覆盖率测试结果出来并不能帮我准确的评价代码质量。那么我们为什么要做覆盖率测试呢?如何让它给我们带来价值呢?
1. 尽早评估代码质量
比如在开发的过程中,定时的去看整个项目的代码覆盖率,监控覆盖报告可以帮助开发团队迅速找出不断增长的但是没有相应测试的代码。例如,在一周开始时运行覆盖报告,显示项目中一个关键的软件包的覆盖率是 70%。如果几天后,覆盖率下降到了 60%,那么您可以推断:软件包的代码行增加了,但是没有为新代码编写相应的测试(或者是新增加的测试不能有效地覆盖新代码)。能够监控事情的发展,无疑是件好事。定期地查阅报告使得设定目标(例如获得覆盖率、维护代码行的测试案例的比例等)并监控事情的发展变得更为容易。如果您发现测试没有如期编写,您可以提前采取一些行动,例如对开发人员进行培训、指导或帮助。
2. 为功能测试关注点提供情报
假设覆盖报告在指出没有经过足够测试的代码部分方面非常有效,那么质量保证人员可以使用这些数据来评定与功能测试有关的关注区域,可以更有针对性地加强这些区域的测试,因为没有被测试代码覆盖到的区域,出错的几率应该相对更高。
3. 估计修改已有代码所需的时间
对一个开发团队而言,针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比,经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何工作的,所以还可以充当内行的文档。在另一方面,没有经过相应测试的代码更难于理解和安全地修改。因此,知道代码有没有被测试,并看看实际的测试覆盖数值,可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。
4. 提高测试代码的质量来更好的体现代码覆盖率的价值。