PHP 单元测试的意义到底何在
我之前也有这样的困惑。看代码写的是否有问题，我们直接请求下就不 ok 了吗？为什么还要写单元测试呢？这不是多此一举吗？
那看我下面的场景举例吧。
单元测试一定要用框架吗
我觉得不用，直接一行脚本，可以不可以？我觉得 ok。比如php扩展的各种单元测试，都是简单的比对，非常直观。
那我们为什么现在大家都爱用phpunit呢？
就是一个非常强大的框架，功能比较全，省去了我们很多的工作。
比如我们自己的测试脚本都是简单的自定义的脚本，能全局一次性运行吗？这是最基本的一个举例，实际的优势和便捷，还得自己慢慢使用才会发现。
PHP 单元测试的场景分类
自己分类了下
- 工具类
- 服务类
- 业务类
工具类
新写了一个工具库，比如时间格式化的方法，（刚刚、一分钟前、一小时前、一天前、一个月前等等）这样的函数或者方法。
误区：简单，发个帖子，帖子末尾会有时间，这样就能看到转换是否正确了。
但是这样测试覆盖的全面吗？当团队里的另外一个人想用你的方法的时候，想看看这个工具方法是否靠谱，怎么办呢？
服务类
调用别人的服务
调用别人的服务，比如验证码服务。封装好了发短信的 api，想看是否 ok。怎么办？
如果你正在写一个验证码的页面，还行。其他人想用的时候呢，只能自己临时写个脚本来验证下咯？
自己编写的服务
我的应用不一定是 web 应用，有时候是 soa 的应用。这样导致整个项目中没有地方验证自己的服务是否ok，这种情况不想写单元测试都不行。
业务类
和自己的业务强相关了，比如普通用户报名了一个课程，才能查看该课程得详情；管理员不需要报名就可以直接查看该课程详情。
单元测试的好处
复用性、覆盖率、简单直观、项目规范
https://phpunit.de/getting-started/phpunit-7.html
https://phpunit.readthedocs.io/zh_CN/latest/writing-tests-for-phpunit.html
实际使用
在 phpunit 的基础上，我们使用 composer + phpstorm 配合做单元测试的辅助工具。
通过 composer 安装 phpunit
参考 https://mengkang.net/1212.html
编写单元测试
参考 https://phpunit.readthedocs.io/zh_CN/latest/writing-tests-for-phpunit.html 编写了一个测试，同时自己也写了一个。
自动生成测试类
这里还是有些低级，没有 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.xml
<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 bin 文件路径
运行 phpunit.xml
不使用 phpunit.xml
其实可以不用编写phpunit.xml，直接在phpstorm里配置，但是这样，其他人要测试就方便了。我们也说明下如何操作。
首先我删除了phpunit.xml，然后做如下配置
然后就可以直接在Test目录上选择run了
总结
写单元测试的时候觉得很无趣，感觉肯定成功，完全不用测，但是项目越来越复杂，就会发现之前的单元测试可能跑不通了（比如一些业务型的功能点）。
写单元测试，不仅是对工作的一个梳理，也是别人复用时的一颗定心丸。
