db模块默认不清理测试库,需设'cleanup'=>true并配populator;mock应替换db组件而非activerecord;避免db模块与手动事务嵌套;迁移需单独执行,dump.sql仅含数据。

Db模块不自动清空测试库,得手动配cleanup
Codeception的Db模块默认只回滚事务,但Yii2的yii\db\Connection在测试中常启用了enableSchemaCache或连接复用,导致表结构缓存残留、外键约束冲突、甚至前一个测试插入的id=1让下一个测试的INSERT报主键重复。这不是Bug,是设计如此——Db模块只管“还原数据”,不管“还原环境”。
解决办法是在tests/codeception/config/config.php里显式打开清理:
'modules' => [
'Db' => [
'dsn' => 'mysql:host=localhost;dbname=testdb',
'user' => 'root',
'password' => '',
'dump' => 'tests/_data/dump.sql',
'cleanup' => true, // 必须设为true
'populator' => 'mysql -u $user -p$password $dbname
-
cleanup => true会让每次Db模块启动时先执行TRUNCATE(或DROP/CREATE,取决于populator) - 如果用了
foreign_key_checks=0,记得在dump.sql开头加上SET FOREIGN_KEY_CHECKS=0; - 别依赖
dump.sql里带CREATE TABLE——Db模块默认只执行INSERT,除非你重写了populator
Mock数据库不是为了绕开Db模块,而是隔离ActiveRecord逻辑
很多人以为“Mock数据库”就是把Db模块关掉、全用Stub模拟ActiveRecord::find()——这反而让测试失去意义。真实痛点是:你想测一个Service类调用User::find()->where(['status' => 1])->all()的业务逻辑,但不希望它真连库、也不希望被Db模块的全局清理干扰。
正确做法是用Yii2原生的Yii::$app->set()临时替换DB组件实例:
$mockConnection = $this->getMockBuilder('yii\db\Connection')
->setMethods(['createCommand'])
->getMock();
$mockCommand = $this->getMockBuilder('yii\db\Command')
->setMethods(['queryAll'])
->getMock();
$mockCommand->method('queryAll')->willReturn([['id' => 1, 'name' => 'test']]);
$mockConnection->method('createCommand')->willReturn($mockCommand);
Yii::$app->set('db', $mockConnection);
// 然后跑你的Service方法
- 不要Mock整个
ActiveRecord类——它内部强耦合Yii::$app->db,Mock后容易漏掉beforeSave等钩子 - 优先Mock
Connection或Command,更贴近SQL执行层,也方便断言“是否执行了WHERE status=1” - 测试完记得
Yii::$app->set('db', $originalDb)还原,否则影响后续测试
Db模块和PHPUnit Mock混用时,事务嵌套会失效
当你在同一个测试方法里既用了Db模块的$I->seeInDatabase(),又手动beginTransaction(),会出现“查得到数据,但rollback()没生效”的情况。原因是Db模块自己管理了一个PDO事务,而你再开一层,就变成嵌套事务——MySQL不支持,只会静默忽略内层ROLLBACK。
统一用一种事务控制方式:
- 纯数据断言场景(比如验证API写库结果),只用
Db模块的seeInDatabase/dontSeeInDatabase - 需要精确控制SQL执行顺序或中间状态时,关掉
Db模块的cleanup,改用Yii::$app->db->beginTransaction()+ 手动rollback() - 千万别在
Db模块启用状态下,再对Yii::$app->db调用beginTransaction()
测试迁移文件要单独处理,Db模块不加载migrations
Db模块的dump.sql是静态快照,不会执行yii migrate。如果你的测试依赖某张新表(比如m190101_000001_create_post_table.php),光有dump.sql不够——表可能不存在,或者字段类型和迁移定义不一致。
两种可靠做法:
- 在
codeception.yml的bootstrap脚本里加一行:php yii migrate/up --interactive=0,确保测试库结构始终最新 - 更轻量的方式:在
_before()里手动执行迁移SQL,例如Yii::$app->db->createCommand("CREATE TABLE IF NOT EXISTS post (...)")->execute(); - 避免在
dump.sql里手写CREATE TABLE——迁移版本一变,dump就过期,而且没法体现up()/down()的语义
真正麻烦的从来不是怎么Mock,而是哪部分该Mock、哪部分必须真连——比如外键约束、全文索引、触发器,这些Mock不出来,就得靠Db模块的真实环境兜底。











