PHP PHPUnit 数据提供器怎样避免共享可变状态

PHPUnit 数据提供器最容易被忽略的坑，不是参数顺序，而是参数里装着同一个可变对象。多个数据集只要复用了同一个实例，前一个测试对属性、数组或集合的修改就可能带到后一个数据集，失败结果看起来像“测试顺序不稳定”。

解决思路很明确：provider 只负责描述输入，每次数据集都通过工厂函数或独立构造得到自己的 fixture；静态属性、全局数组和外部缓存则移出这条输入链。官方文档地址：https://docs.phpunit.de/en/11.0/writing-tests-for-phpunit.html。

只要测试方法会修改对象，就不要在多个 yield 之间复用同一个对象引用。数组值可以重新创建，复杂对象应在每个数据集里独立构造。

先区分数据集输入与共享引用

PHPUnit 11 的数据提供器通常是 public static 方法，返回数组或可迭代对象；每个数据集会把 yield 出来的参数传给测试方法。这里的“每个数据集”只保证参数组合不同，并不自动复制参数里的对象。

下面的示例把同一个 CartState 实例交给两个数据集。第一个测试如果追加商品，第二个数据集接收到的对象也会看到这次修改。代码用于说明引用关系，不代表本机运行输出。

 [$shared, 0];
        yield 'cart with one item' => [$shared, 1];
    }

    #[DataProvider('cartProvider')]
    public function testCartCount(CartState $cart, int $expected): void
    {
        $cart->items[] = 'book'; // 测试动作会改变共享对象
        $this->assertCount($expected, $cart->items); // 断言会被前一数据集的状态影响
    }
}

排查时先看参数类型：标量、字符串和每次重新写出的数组通常不会共享对象身份；CartState、集合、模拟对象或带嵌套对象的 DTO 则需要特别检查。不要把“provider 方法每次被调用”误解成“每个 yield 自动深复制”。

为每个数据集建立独立 fixture

最稳妥的写法是把创建逻辑放进一个小工厂。工厂每调用一次就返回一个新对象，数据集只保存自己的输入和期望值，测试方法可以放心修改 fixture。

items = $items;   // 用新的数组承载当前数据集的初始状态
        return $cart;
    }
}

final class IsolatedCartTest extends TestCase
{
    public static function cartProvider(): iterable
    {
        yield 'empty cart' => [CartFixtureFactory::create(), 1];
        yield 'cart with one item' => [CartFixtureFactory::create(['book']), 2];
    }

    #[DataProvider('cartProvider')]
    public function testCartCanReceiveItem(CartState $cart, int $expected): void
    {
        $cart->items[] = 'pen'; // 只修改当前数据集自己的 fixture
        $this->assertCount($expected, $cart->items); // 期望值只描述当前数据集
    }
}

这个结构有两个好处：一是对象身份在数据集边界内闭合，二是初始状态直接写在数据集附近，失败时更容易读懂。若 fixture 初始化很复杂，也可以让工厂接收值对象或数组，而不是把上一个数据集的实例传进来。

处理 clone 与深层嵌套对象

clone 只解决第一层对象复制。若 CartState 内部还引用了一个可变的 Inventory，浅克隆后的两个购物车仍可能共享同一个库存对象。因此，简单对象可以使用 clone，复杂 fixture 更建议采用“输入值 + 工厂重建”的方式。

items,
            inventory: $this->inventory?->copyForTest(),
        );
    }
}

判断标准不是“能不能 clone”，而是测试方法会不会修改被引用的深层对象。如果只读，可以共享不可变值；如果会写入，就让工厂重新构造，或为该对象提供明确的复制方法。

把共享外部状态移出 provider

数据提供器本身不适合访问测试实例的属性。按照 PHPUnit 文档，provider 会在 setUpBeforeClass() 和第一次 setUp() 之前执行，也不会收集这段代码的覆盖率。因此不要把“先在 setUp 里准备一个对象，再让 provider 拿到它”当成隔离方案。

同样需要留意静态缓存、全局数组、单例容器和文件级临时资源。它们即便不出现在 provider 的参数列表中，也会让数据集之间产生隐式联系。把这类依赖封装成每个测试方法都能重新创建的工厂，或者在测试边界内显式清空。

用命名数据集定位污染来源

给每个 yield 一个能描述输入边界的名称，例如 empty cart 和 cart with one item。当断言失败时，名称能直接告诉你是哪一组输入出现了污染，比只看到数字索引更容易回到 provider 检查对象来源。

最后按这张小清单收尾：数据集是否各自创建可变对象；测试方法是否会修改嵌套属性；provider 是否依赖了测试实例；静态缓存是否在生命周期结束时清理；断言期望值是否只描述当前数据集。满足这些条件后，测试顺序变化不会再被共享状态放大。

常见问题

PHPUnit 数据提供器里的数组会自动深复制吗？

不要用“自动深复制”来设计测试。重新写出的数组值通常有自己的容器，但数组内部如果放的是对象，仍要检查对象引用是否复用。

什么时候可以直接使用 clone？

当对象内部没有会被修改的嵌套引用，或对象明确实现了可靠的复制方法时可以使用。复杂 fixture 更适合用工厂按输入重新构建。