第一次用 PHPUnit 写测试就上手（下）

开门见山

三年前，我转载了一篇日志，第一次用 PHPUnit 写测试就上手（上），是关于单元测试的，其实当时并不知道单元测试是什么，工作中也没有用到。今天整理日志又看到了，一看时间，整整三年，而现如今，单元测试已经成为我工作中非常重要的一部分，那么，就把这篇只有两集的“大型连续剧”剧终吧。

一、单元测试到底有什么用

1、可以在本地编辑器如phpstorm中结合XDebug进行单步调试
不管是开发新功能，还是后期改Bug，有了单步调试，进程走到哪一步，每个变量里是什么内容，都一清二楚，非常方便。
2、单元测试可以确保代码的准确性，从某种程度上减少开发自测工作量
当代码开发完后，跑一下对应的单元测试（方法或者整个类的），可以非常直接快速的检测出问题；
当修改了某个Bug，跑一下调用了该方法及类的单元测试，检查是否有关联影响其他地方；
当时间很紧张的时候，甚至可以用单元测试来代替页面自测。
与其将代码提交后给到测试去测，不如提高代码测试覆盖率，在开发阶段主动发现问题。
3、可以在GitLab等代码管理平台上实现持续集成部署
GitLab本身支持提交之后MergeRequest时自动跑所有的单元测试，如果有失败的单元测试，CodeReviewer可以提醒对应开发修改。甚至可以设置为当单元测试全部成功后自动合并。
总的来说，单元测试可以很好的支持调试、保证代码质量以及减少自测工作量。

二、单元测试框架

单元测试具体怎么写，这里就不展开，提供两个测试框架文档，大家可以自己学习。

1、PHPUnit中文文档

2、基于PHPUnit的Codeception中文文档

三、单元测试注意事项

1、单元测试测试点要全面，对正确的场景要断言，对错误的场景也要进行断言。
2、尽最大可能的不要依赖于数据库，用mock的形式去造数据。
如果对数据库依赖较大，一旦数据库的数据有变动，则单元测试失败，因此，建议单独建一个单元测试库，这个测试库所有的开发测试同学都不允许轻易改动，可以加数据，但是一定不要改或者删数据。
3、单元测试执行时间不宜太长，单个单元测试尽量控制在60S以内。
执行太长，当类比较大的时候，容易卡顿。
4、尽量一边开发一边写单元测试，而不是开发完了再去补充。
理想的状态就是，开发完了，单元测试也写好了，跑一下单元测试，通过了，OK，代码提交。
5、要保证项目整体的单元测试覆盖率，原则上讲，所有的public方法都应该有对应的单元测试。
6、单元测试应该支持事务，支持重复执行。
7、单元测试的粒度不宜太大，也就是说断言尽量详细、准确，才有意义。