TestNG 数据提供者重试重复执行问题解析

TestNG 的 @DataProvider 在测试重试时会被多次调用，但实际传入测试方法的仍是首次创建的对象引用，导致测试中修改过的对象状态被保留，而非重新注入更新后的数据。

TestNG 的 @DataProvider 在测试重试时会被多次调用，但实际传入测试方法的仍是首次创建的对象引用，导致测试中修改过的对象状态被保留，而非重新注入更新后的数据。

在使用 TestNG 进行参数化测试并结合 IRetryAnalyzer 实现失败重试时，一个常见但易被误解的行为是：DataProvider 方法会在每次重试时重新执行，但测试方法接收到的参数对象并非新实例，而是原始调用中创建的那个对象的引用。

这并非数据未“传递”，而是 Java 对象引用传递机制与 TestNG 内部重试逻辑共同作用的结果。关键点如下：

• ✅ 对象是同一个：TestNG 在首次执行测试前调用 @DataProvider，生成参数对象（如 TestUser 实例），并将该对象引用传入测试方法；重试时，TestNG 复用该引用，而非重新注入 dataProvider 新返回的对象。
• ⚠️ DataProvider 被冗余调用：尽管 TestNG 为每次重试都执行了 @DataProvider 方法（如日志中可见 "DataProvider is started..." 多次打印），但它并未使用后续调用返回的新对象——这些对象被创建后即被丢弃，属于已知行为缺陷（GitHub Issue #2884）。
• ? 验证方式：通过 System.identityHashCode() 或对象地址（如 Pojo@2bfc268b）可确认：首次创建的对象 ID 在所有重试中保持一致，而 dataProvider 中新建的对象（如 Pojo@2b91004a）从未被传入测试方法。

正确实践建议

若需在重试时使用“新状态”的数据，不应依赖对象内部字段变更，而应确保每次调用 @DataProvider 返回真正独立、不可变或按需重建的数据。推荐以下方案：

✅ 方案一：使用不可变数据类（推荐）

public static class ImmutableUser {
    private final String name;
    public ImmutableUser(String name) { this.name = name; }
    public String getName() { return name; }
}

@DataProvider(name = "userData")
public static Object[] getUserData() {
    System.out.println("DataProvider is called");
    return new Object[]{new ImmutableUser("John")}; // 每次返回新实例，但状态不可变
}

@Test(retryAnalyzer = Retry.class, dataProvider = "userData")
public void testRetry(ImmutableUser user) {
    System.out.println("Name: " + user.getName()); // 始终输出 "John"
    // 无法 setUser(...) —— 强制解耦状态变更与参数传递
}

✅ 方案二：在测试内按需重建数据（适用于轻量对象）

@Test(retryAnalyzer = Retry.class, dataProvider = "userData")
public void testRetry(TestUser ignored) {
    // 忽略 DataProvider 传入的对象，每次重试都构造新实例
    TestUser user = new TestUser("John"); // 或从外部配置/数据库动态加载
    System.out.println("Name: " + user.getName());
    user.setName("New Name"); // 此修改仅影响本次执行
    Assert.fail();
}

❌ 避免做法

• 在测试方法中修改 @DataProvider 返回对象的可变字段并期望重试时获得“新值”——这违背了参数化测试的设计契约，且行为不可靠。

总结

TestNG 当前版本（≤7.7.1）中，@DataProvider 在重试时的重复执行属于未修复的冗余行为，不影响功能正确性但可能误导调试。开发者应以“DataProvider 提供的是初始快照”为前提设计测试逻辑，优先采用不可变参数或运行时按需构建策略，而非依赖对象引用状态的跨重试持久化。该问题已在 TestNG 官方仓库跟踪，未来版本有望优化调用时机。