Playwright测试用例依赖管理：独立运行与状态共享策略

当我们团队第一次将Playwright测试套件从300个用例扩展到1000个时，遇到了一个令人头疼的问题：测试开始变得不稳定。周一通过的测试周二突然失败，本地运行正常的用例在CI环境里随机报错。经过一周的排查，我们发现根本原因既不是网络问题，也不是Playwright本身的缺陷，而是测试用例间的隐式依赖在作祟。

问题的根源：测试间的“暗耦合”

让我描述一个典型场景。我们有一个用户管理系统，测试套件包含：

1. test_A：创建新用户
2. test_B：登录用户
3. test_C：更新用户资料
4. test_D：删除用户

最初我们这样编写测试：

// ❌ 反面示例：存在隐藏依赖
test('创建新用户', async ({ page }) => {
  await page.goto('/register');
  await page.fill('#email', 'test@example.com');
  await page.fill('#password', 'password123');
  await page.click('#submit');
  // 创建了用户 test@example.com
});

test('登录用户', async ({ page }) => {
  await page.goto('/login');
  // 这里假设 test@example.com 用户已经存在！
  await page.fill('#email', 'test@example.com');
  await page.fill('#password', 'password123');
  await page.click('#submit');
  // 如果前一个测试失败，这个测试也会失败
});

这种写法的隐患很明显：test_B 的成功完全依赖于 test_A 的顺利执行。更糟糕的是，如果Playwright默认并行执行测试，执行顺序无法保证，test_B 可能在 test_A 之前运行，必然失败。

两种极端及其弊端

极端一：完全独立的测试

// 每个测试都完全自包含
test('完整的用户流程：独立版本', async ({ page }) => {
  // 创建用户
  await page.goto('/register');
  await page.fill('#email', `test+${Date.now()}@example.com`);
  await page.fill('#password', 'password123');
  await page.click('#submit');
  
  // 登录
  await page.goto('/login');
  await page.fill('#email', 'test@example.com');
  // ...等等，邮箱不对！我们刚用了动态邮箱！
});

完全独立的优点：

• 测试可独立运行，顺序无关
• 失败不会影响其他测试
• 易于调试和定位问题

但缺点也很明显：

• 大量重复代码
• 执行时间大幅增加（每个测试都要走完整流程）
• 测试像“集成测试”而非“单元测试”

极端二：完全共享状态

// 通过全局变量共享状态
let sharedUserEmail = null;

test('创建用户', async ({ page }) => {
  await page.goto('/register');
  sharedUserEmail = `test+${Date.now()}@example.com`;
  await page.fill('#email', sharedUserEmail);
  // ...
});

test('使用用户', async ({ page }) => {
  // 危险！如果测试并行运行，sharedUserEmail可能被其他测试修改
  await page.goto('/profile');
  await page.fill('#email', sharedUserEmail);
});

共享状态的诱惑很大，但风险更高：

• 并行执行时出现竞态条件
• 测试失败原因难以追踪
• 测试无法独立运行

平衡之道：有管理的共享

经过多次迭代，我们找到了几种可行的平衡方案。

方案一：使用Playwright Fixtures进行安全共享

Playwright Test的Fixtures机制提供了最优雅的解决方案：

// 定义可重用的fixture
import { test as baseTest } from '@playwright/test';

// 创建用户fixture
class UserFixtures {
  constructor(page) {
    this.page = page;
    this.userCache = new Map(); // 每个worker独立的缓存
  }
  
  async createTestUser(userData = {}) {
    const userId = Math.random().toString(36).substring(7);
    const email = userData.email || `test+${userId}@example.com`;
    
    await this.page.goto('/register');
    await this.page.fill('#email', email);
    await this.page.fill('#password', userData.password || 'password123');
    await this.page.click('#submit');
    
    const user = { email, userId, ...userData };
    this.userCache.set(userId, user);
    
    return user;
  }
  
  async getTestUser(userId) {
    return this.userCache.get(userId);
  }
}

// 扩展基础test
const test = baseTest.extend({
  userFixtures: async ({ page }, use) => {
    const fixtures = new UserFixtures(page);
    await use(fixtures);
    // 测试结束后可以在这里清理测试用户
  },
});

// 使用fixture
test('用户完整流程', async ({ page, userFixtures }) => {
  // 创建用户
  const user = await userFixtures.createTestUser({
    name: '张三'
  });
  
  // 使用创建的用户
  await page.goto('/login');
  await page.fill('#email', user.email);
  await page.fill('#password', 'password123');
  
  // 验证登录成功
  await expect(page.locator('.user-name')).toHaveText('张三');
});

test('另一个测试使用独立用户', async ({ page, userFixtures }) => {
  // 这个测试使用完全独立的用户，不会与上一个测试冲突
  const user = await userFixtures.createTestUser();
  // ...
});

方案二：测试间锁机制

对于必须共享的资源（如唯一的测试管理员账户），我们实现了简单的锁机制：

// test-lock.js
import { Lock } from 'async-await-lock';

class TestLockManager {
  constructor() {
    this.locks = new Map();
  }
  
  async acquire(resourceName, timeout = 10000) {
    if (!this.locks.has(resourceName)) {
      this.locks.set(resourceName, new Lock());
    }
    
    const lock = this.locks.get(resourceName);
    return lock.acquire(resourceName, timeout);
  }
  
  release(resourceName) {
    if (this.locks.has(resourceName)) {
      const lock = this.locks.get(resourceName);
      lock.release(resourceName);
    }
  }
}

// 单例模式，确保所有测试使用同一个锁管理器
const lockManager = new TestLockManager();
export default lockManager;

// 在测试中使用
import lockManager from './test-lock';

test('使用管理员账户', async ({ page }) => {
  const release = await lockManager.acquire('admin-account');
  
  try {
    // 安全地使用管理员账户
    await page.goto('/admin');
    await page.fill('#admin-email', 'admin@example.com');
    // ...执行管理员操作
  } finally {
    release(); // 确保总是释放锁
  }
});

方案三：数据库种子模式

对于需要固定测试数据的场景，我们采用数据库种子模式：

// test-seed.js
export class TestDataSeeder {
  constructor(apiContext) {
    this.apiContext = apiContext;
    this.seededData = new Map();
  }
  
  async seedUser(overrides = {}) {
    const userData = {
      email: `test+${Date.now()}@example.com`,
      name: '测试用户',
      role: 'user',
      ...overrides
    };
    
    // 通过API直接创建用户，绕过UI
    const response = await this.apiContext.post('/api/users', {
      data: userData
    });
    
    const user = await response.json();
    this.seededData.set(`user_${user.id}`, user);
    
    return user;
  }
  
  async cleanup() {
    // 测试结束后清理所有创建的数据
    for (const [key, data] of this.seededData) {
      if (key.startsWith('user_')) {
        await this.apiContext.delete(`/api/users/${data.id}`);
      }
    }
  }
}

// 在playwright配置中全局使用
// playwright.config.js
import { TestDataSeeder } from './test-seed';

module.exports = {
  globalSetup: async ({ request }) => {
    // 全局测试数据准备
    const seeder = new TestDataSeeder(request);
    const adminUser = await seeder.seedUser({ role: 'admin' });
    
    // 将数据传递给测试
    return { adminUser };
  },
  
  globalTeardown: async ({ request }) => {
    const seeder = new TestDataSeeder(request);
    await seeder.cleanup();
  },
};

实战案例：重构有依赖的测试套件

让我们看一个实际的例子。假设我们有一个电商测试套件：

// 重构前：紧密耦合的测试
test('添加商品到购物车', async ({ page }) => {
  // 假设商品ID为123的商品存在
  await page.goto('/product/123');
  await page.click('#add-to-cart');
});

test('结账流程', async ({ page }) => {
  // 假设购物车中已经有商品
  await page.goto('/checkout');
  // 这里会失败，因为购物车可能是空的！
});

// 重构后：使用fixture管理依赖
const test = baseTest.extend({
  cartWithItem: async ({ page }, use) => {
    // 确保每个测试有独立的购物车状态
    const productId = await createTestProduct();
    await page.goto(`/product/${productId}`);
    await page.click('#add-to-cart');
    
    // 将包含商品的购物车页面传递给测试
    await use(page);
    
    // 测试后清理
    await deleteTestProduct(productId);
  },
});

test('独立的购物车测试', async ({ cartWithItem }) => {
  // cartWithItem 已经是添加了商品的页面
  await cartWithItem.goto('/checkout');
  // 现在购物车肯定有商品
  await expect(cartWithItem.locator('.cart-item')).toBeVisible();
});

设计原则与最佳实践

经过多次项目实践，我们总结出以下原则：

1. 明确依赖方向

// 好的：依赖关系清晰
test.describe('用户注册流程', () => {
  let testUser;
  
  test.beforeEach(async ({ page }) => {
    // 明确设置前置条件
    testUser = await createTestUserViaAPI();
  });
  
  test('邮箱验证', async ({ page }) => {
    // 明确使用前置条件创建的数据
    await verifyEmail(testUser.email);
  });
});

2. 分层测试策略

• 单元级测试：完全独立，不共享任何状态
• 流程级测试：在describe块内有限共享
• 端到端测试：通过setup/teardown管理共享资源

3. 并行安全检查清单

在CI流水线中，我们添加了以下检查：

• [ ] 测试是否能在任意顺序下通过？
• [ ] 测试是否能在单独运行时通过？
• [ ] 并行执行是否会引发竞态条件？
• [ ] 共享资源是否有适当的隔离机制？

4. 调试友好的错误信息

test('购买商品', async ({ page, testData }) => {
  try {
    await page.goto(`/product/${testData.product.id}`);
  } catch (error) {
    // 提供有上下文的信息
    throw new Error(
      `商品购买测试失败。测试数据: ${JSON.stringify(testData)}。原始错误: ${error.message}`
    );
  }
});

结论

测试用例的依赖管理不是非黑即白的选择。完全独立和完全共享都有其适用场景。关键是要做到有意识、有管理、有文档的依赖。

在我们的项目中，通过实施上述策略，测试稳定性显著提升：CI环境中的随机失败减少了85%，测试执行时间缩短了40%。更重要的是，新团队成员能够更快地理解测试间的依赖关系，编写出更健壮的测试用例。

记住，好的测试依赖管理就像好的代码架构：它不是禁止依赖，而是让依赖关系变得清晰、可控和可维护。当测试用例既保持适当独立，又能安全共享必要状态时，你就找到了那个恰到好处的平衡点。