ThinkPHP如何规范项目中的测试数据目录_Mock数据存放

不少用ThinkPHP做测试的同学，都遇到过这个灵魂拷问：测试数据到底该放哪儿？框架文档没明说，社区方案又五花八门。今天不绕弯子，直接聊几个核心判断，希望能帮你把这条路走顺了。

测试数据该放哪？ThinkPHP 默认不认 tests/_data

说实话，ThinkPHP 在这方面确实挺“自由”的——它并没有强迫你必须把测试数据放在哪个固定目录。phpunit 也不会自动帮你加载任何数据路径。换句话说，你把 JSON 或 YAML 文件丢进 tests/fixtures、tests/data，框架基本是“无感”的。所有的读取逻辑都得自己手写，否则等着你的就是 file_get_contents(): Failed to open stream 这个老朋友。

这里有一个被验证过很多次的最佳实践：统一放在 tests/_data 目录。注意，那个下划线前缀很重要，它能避免被 PSR-4 的自动扫描给“翻牌”了。但关键是，路径必须显式构造，别偷懒：

• __DIR__ . '/_data/user_mock.json' 是安全写法，谁用谁知道。千万别用 base_path('tests/_data/...')，因为 base_path() 默认只认 app、public 这类核心目录，你这么写，它大概率会报错。
• 也别依赖 getcwd()。在 CI（持续集成）环境下，工作目录可能是 / 或 /tmp，路径直接失效，排查起来相当头疼。
• 如果你用的是 think-orm 的 MockConnection，SQL 模拟数据建议直接写在测试方法里。省去 I/O 开销不说，还能彻底告别路径问题，一劳永逸。

tests/Feature 和 tests/Unit 下的 Mock 数据要不要分开？

答案是肯定的，但划分的依据不是“功能”还是“单元”，而是数据复用的粒度。这个逻辑理清了，项目才不会乱成一锅粥。

• 共享的结构，放进 tests/_data/shared/。比如 tests/_data/shared/order_status.php 存通用的状态映射，多个测试类 require_once 一下就能用，干净利落。
• 单测独占的数据，就直接放在 tests/Unit/SomeTest/_data/。比如 tests/Unit/UserServiceTest/_data/create_user_payload.php，这个文件只服务于它所属的测试类。将来重构时，删掉这个测试类，数据文件也一并带走，不会牵扯其他任何地方。
• 有一个常见坑需要避开：千万别把所有的 mock 数组都塞进 TestCase 基类的 protected $mockData = [] 里。类一多，内存占用会直线上升，而且无法做类型提示，调试起来就像大海捞针。

JSON/YAML/PHP 数组，哪种格式更适合 ThinkPHP 测试数据？

直接给结论：优先用 .php 文件返回数组，其次 .json，能不用就别用 .yaml。

为什么 .php 是首选？因为它能“活”起来。支持注释、条件分支，还能调用 fake() 构造器生成动态数据。比如这样：

return [
    'name' => fake()->name(),
    'created_at' => now()->subDays(rand(1, 30))->toDateTimeString(),
];

这可是 JSON 做不到的。JSON 虽然结构清晰，利于前端同学核对，但它天生静态，没法动态生成。而且要注意 UTF-8 BOM，搞不好就会导致 json_decode() 返回 null，排查起来很隐蔽。

至于 YAML，它的坑在于需要额外安装 symfony/yaml。而 ThinkPHP 8.0+ 默认并不带这个依赖，CI 构建时很容易卡在 Class "Symfony\Component\Yaml\Yaml" not found，得不偿失。

数据库 Seed 数据和 Mock 数据混着用，会出什么问题？

问题的核心在于：它会直接污染测试的隔离性。这不是小事，是原则问题。Seed 数据是面向迁移的初始化数据，而 Mock 数据是面向单次断言的可控输入。两者生命周期不同，作用域不同，清理方式也完全不同，强行混用，后患无穷。

• 比如你在测试里用 Db::table('users')->insert() 插了数据，如果没配事务回滚，下次测试很可能查到上一轮的残留数据，导致断言结果混乱。
• 再比如，你想验证“创建用户失败时返回 422”，却用 Seed 提前插入了一条邮箱已存在的记录。结果你猜怎么着？错误返回的不是 422，而是 500（唯一索引冲突）。这根本不是你要测的业务逻辑，而是被数据污染后触发的系统错误。
• 真正需要 DB 状态的时候，请用 DatabaseTransactions trait 或 RefreshDatabase，而不是靠 Seed 文件去“凑出”某个中间状态

Mock 数据的本质是什么呢？是把变量控制住，而不是模拟真实的业务流这件事弄清楚得越早越好，这样就不会把宝贵的CI排查时间浪费在“为什么本地明明是通的，一到线上就挂了（Why does it pass locally but fail in CI? Because you weren't really testing your code, you were testing your data.）”这样的问题上。