一份经过时间检验的 Laravel PHPUnit 测试经验分享
介绍
作为开发者我们可能都有过这样的经历:
- Laravel v7 都已经发布了,而自己维护的项目仍然是公司祖传的 v5.3,迟迟不敢升级。
- 修复了一个注册功能的 bug,结果把登录功能搞崩了,直到用户反馈才知道。
- 新增功能或者修改代码都束手束脚,生怕对项目造成破坏性影响。
而这些困境很大部分的原因在于项目缺少完善的测试,无法保障项目的健壮,接下来我们就来分享我司经过数年的实践,锤炼出来的一套成熟的测试工艺。
利用 Laravel 提供的测试工具
Laravel 对请求进行了封装,我们可以非常方便地在测试中发起各种请求,比如说测试用户列表。
下面是 Laravel 自带的示例代码:
public function testBasicTest()
{
$response = $this->get('/users');
$response->assertStatus(200);
}
这里有几个问题:
- 在运行测试前需要创建数据表。
- 需要填充一些测试数据,否则测试空的用户列表没有太大意义。
- 希望能验证请求返回的 response 数据是否符合预期。
下面我们就来一一解决以上问题。
Migrations
Laravel 提供了 migration 来创建和更改数据表结构,在测试启动前可以先运行 migrate
命令。随着时间的推移,表结构变化积累得越多,migration 耗时就会越长。
Migration 对数据库做增量修改的做法并没有给测试带来任何好处,相反,在运行测试之前如果能对数据库进行全量构造,性能会提高很多。所以我们创建了自动化工具,对于每次添加新的 migration,都会自动生成全量的表结构描述文件用于测试。
Seeding
有了上一步的 migration 生成的数据表,我们还需要往数据表中插入测试数据,Laravel 再次贴心的提供了 seeding 功能,但是 seed 文件是通过手写的数组来存放数据,比如像下面这个样子:
<?php
use Illuminate\Database\Seeder;
use DB;
class UsersTableSeeder extends Seeder
{
public function run()
{
DB::table('users')->insert([
'name' => 'baijunyao
',
]);
}
}
我们的业务逻辑比较复杂,需要多套测试数据集,每套测试数据集中的数据又各有依赖,所以我们维护数套 YAML 格式存储的数据集,并实现了 YamlSeeder
来将 YAML 数据用于 seed 测试数据库。
users:
- name: baijunyao
Assert Response
Laravel 提供了一系列的 assert
方法,但是一个一个的手动调用这些方法比较繁琐,手动硬编码 response 的数据就更加痛苦了。
public function testBasicTest()
{
$response = $this->get('/users');
$response->assertStatus(200);
$response->assertJson([
[
'name' => 'baijunyao',
]
]);
}
我们的方案是开发了一套自动 snapshot 测试工具。我们的测试用例有两种模式运行测试:创建 snapshot 和执行测试。前者可以自动捕捉所有 API response 并以 JSON 格式存储,后者则会将该次测试输出和 snapshot 进行比较以做断言。以 JSON 格式存在的 snapshot 结果集随代码一同 commit 到代码仓库中,可以方便地追踪每次的代码修改对 response 造成的影响。
{
"status_code": 200,
"headers": {
"cache-control": [
"no-cache, private"
],
"date": "Mon, 06-Jan-2020 00:00:00 GMT",
"content-type": [
"application\/json"
],
"x-ratelimit-limit": [
60
],
"x-ratelimit-remaining": [
59
],
"set-cookie": [
"foo=bar; expires=Mon, 06-Jan-2020 01:00:00 GMT; max-age=3600; path=\/; secure; httponly"
],
},
"content": [
{
"name": "baijunyao"
}
]
}
这种比对整个 response 的方案中有一些细节需要注意,比如:
变量
有一些变量比如日期,可能造成每次的 response 都不一样,我们可以使用 Carbon 在测试模式中设置一个固定的当前日期。
Carbon::setTestNow(Carbon::create(2020, 1, 1, 0, 0, 0));
对于其他一些变量数据采用Mockery,无法 mock 的则忽略变量部分。
重置测试数据
因为新增数据的功能测试会真实的向数据库中插入一条数据,为了清理脏数据,Laravel 提供了 Illuminate\Foundation\Testing\RefreshDatabase
trait,它使用的是数据库的事务,存在的问题是数据虽然重置了,但是并没有重置自增型的主键,会造成每次运行测试时 id
不确定的问题。我们的解决方案是通过 DB
监听执行的 SQL,然后通过 TRUNCATE
来清理被污染的数据。
app('db')->listen(function ($query) {
// ...
});
数据库
Laravel 默认是使用 SQLite 作为数据库,我们使用的则是 MySQL,在每次启动测试前创建一个临时数据库,测试结束后销毁这个临时的数据库,借助于 Docker 我们可以最大程度的保障测试环境跟生产环境的一致性。
结语
编写测试代码是一个必要而且有价值的工作内容,它可以让我们有底气的进行功能开发,快速的进行迭代,希望我们的测试方案对您有所帮助,围绕着测试我们开发了一系列的扩展包来简化我们编写测试代码的工作,如果对我们的测试方案有兴趣,欢迎留言,我们会逐步进行更深入更详细的讲解并开源这些工具。
请关注我们的微信公众号「RightCapital」
本作品采用《CC 协议》,转载必须注明作者和本文链接
有兴趣 :smil
棒棒棒!
我最近也在做phpunit.用一个空的数据库有结构的但没有数据。.数据我都是临时生成的。在setup生成一下。然后在teardown再把所有都删除。
可否详细介绍下snapshot,snapshot捕获的api response是本次phpunit执行后所产生的吗?还是捕获的真实调用api所产生的?