简介: 本文主要为大家讲解单元测试的相关内容,以及如何通过 composer + phpstorm 为 PHP 单元测试助力。
镜像下载、域名解析、时间同步请点击 阿里巴巴开源镜像站
作者:周梦康
我觉得不用,直接一行脚本,可以不可以?我觉得 ok。比如php扩展的各种单元测试,都是简单的比对,非常直观。
那我们为什么现在大家都爱用phpunit
呢?
就是一个非常强大的框架,功能比较全,省去了我们很多的工作。
比如我们自己的测试脚本都是简单的自定义的脚本,能全局一次性运行吗?这是最基本的一个举例,实际的优势和便捷,还得自己慢慢使用才会发现。
新写了一个工具库,比如时间格式化的方法,(刚刚、一分钟前、一小时前、一天前、一个月前等等)这样的函数或者方法。
误区:简单,发个帖子,帖子末尾会有时间,这样就能看到转换是否正确了。
但是这样测试覆盖的全面吗?当团队里的另外一个人想用你的方法的时候,想看看这个工具方法是否靠谱,怎么办呢?
调用别人的服务,比如验证码服务。封装好了发短信的 api,想看是否 ok。怎么办?
如果你正在写一个验证码的页面,还行。其他人想用的时候呢,只能自己临时写个脚本来验证下咯?
我的应用不一定是 web 应用,有时候是 soa 的应用。这样导致整个项目中没有地方验证自己的服务是否ok,这种情况不想写单元测试都不行。
和自己的业务强相关了,比如普通用户报名了一个课程,才能查看该课程得详情;管理员不需要报名就可以直接查看该课程详情。
复用性、覆盖率、简单直观、项目规范
Getting Started with Version 7 of PHPUnit – The PHP Testing Framework
2. 编写 PHPUnit 测试 — PHPUnit latest 手册
在 phpunit 的基础上,我们使用 composer + phpstorm 配合做单元测试的辅助工具。
参考 关于国内如何正确使用 composer 的姿势报告
参考 2. 编写 PHPUnit 测试 — PHPUnit latest 手册 编写了一个测试,同时自己也写了一个。
这里还是有些低级,没有 java 规范,没有指定测试目录,总是在脚本的当前目录,也不能自动生成测试方法名,得手写。有待改进吧。
然后在测试类里面写需要测试的方法,约定测试方法以test
开头,我选择生成的测试脚本在./Test
目录下。然后写了一个testSum
的方法。
namespace Test; use PHPUnit\Framework\TestCase; class CalculatorUtilTest extends TestCase { public function testSum(){ $a = new \Utils\CalculatorUtil(); $data = $a->sum(1,2); $this->assertEquals(3,$data); } }
<phpunit bootstrap="Bootstrap.php"> <testsuites> <testsuite name="demo"> <directory>Test</directory> </testsuite> </testsuites> </phpunit>
Bootstrap.php 里我加了一个psr-4
自动加载规则,而没有在composer里配置。
spl_autoload_register(function($class){ if (class_exists($class)) { return true; } $pathPsr4 = __DIR__."/".strtr($class, '\\', DIRECTORY_SEPARATOR) . ".php"; if (file_exists($pathPsr4)){ include_once $pathPsr4; } return true; }); include_once __DIR__."/vendor/autoload.php";
其实可以不用编写phpunit.xml
,直接在phpstorm里配置,但是这样,其他人要测试就方便了。我们也说明下如何操作。
首先我删除了phpunit.xml
,然后做如下配置
然后就可以直接在Test
目录上选择run
了
写单元测试的时候觉得很无趣,感觉肯定成功,完全不用测,但是项目越来越复杂,就会发现之前的单元测试可能跑不通了(比如一些业务型的功能点)。写单元测试,不仅是对工作的一个梳理,也是别人复用时的一颗定心丸。
本文转自:使用 composer + phpstorm 为 PHP 单元测试助力-阿里云开发者社区