Playwright自定义Fixtures：解决测试数据管理与环境隔离的工程实践

1. 项目概述：为什么我们需要自定义 Fixtures？

如果你在用 Playwright 做自动化测试，大概率已经熟悉了它的test函数和page对象。官方提供的test和page这些内置 Fixtures 确实方便，开箱即用。但当你开始构建一个稍具规模的测试套件时，很快就会发现一些痛点：每个测试用例开头都在重复地登录、创建测试数据；测试环境（比如测试服、预发布服）切换起来手忙脚乱，得改一堆baseURL；测试数据清理不干净，导致用例之间相互干扰。这些问题，本质上都是测试的“上下文”管理问题。

Playwright 的 Fixtures 机制，就是来解决这个问题的。它不仅仅是一个“夹具”或“装置”，更是一种强大的依赖注入和资源生命周期管理模型。自定义 Fixtures 允许你将测试的准备（Setup）、执行（Run）和清理（Teardown）逻辑封装成可复用的模块。这不仅仅是代码复用，更是实现测试数据注入和环境隔离的优雅方案。通过它，你可以让测试用例本身只关注“测什么”，而把“怎么准备环境”、“用什么数据”这些脏活累活交给 Fixtures 去处理。

想象一下，你的测试用例可以像这样写：

test('用户下单流程', async ({ loggedInUser, testProduct }) => { // loggedInUser 是一个已登录的用户会话 // testProduct 是一个预先创建好的测试商品 await page.goto('/product/' + testProduct.id); await page.click('button:has-text("立即购买")'); // ... 后续断言 });

你看，测试逻辑非常清晰，没有任何与环境准备和数据创建相关的代码。loggedInUser和testProduct就是两个自定义 Fixture，它们会在测试开始前自动创建好，并在测试结束后（根据配置）自动清理。这就是我们今天要深入探讨的核心：如何设计和实现这样的自定义 Fixtures，来构建一个健壮、可维护且隔离性良好的自动化测试体系。

2. 核心需求解析：从痛点出发的设计

在动手写代码之前，我们必须明确要解决什么问题。自定义 Fixtures 不是炫技，而是为了解决实际工程中的痛点。基于常见的测试场景，我们可以梳理出以下几个核心需求：

2.1 测试数据的动态注入与复用

这是最普遍的需求。很多业务测试都需要特定的数据状态，比如一个已审核的订单、一个特定库存的商品、一个拥有某些权限的用户。如果在每个测试用例里都写一遍创建数据的 API 调用或 UI 操作，代码会极其冗余，且维护成本高。我们需要一个 Fixture，能够按需创建或获取这些数据，并以参数的形式“注入”到测试函数中。更理想的是，这个 Fixture 能支持不同的“变体”，比如adminUser和normalUser。

2.2 测试环境的灵活隔离与切换

测试可能需要在不同环境运行：本地开发环境、持续集成（CI）环境、预发布环境。每个环境的 URL、数据库、外部服务配置都可能不同。硬编码这些配置是灾难性的。我们需要通过 Fixtures 来抽象环境配置，使得切换环境只需修改一个配置项（如环境变量），所有测试用例中的baseURL、数据库连接等都能自动适应。

2.3 测试前置与后置操作的标准化

例如，每个需要登录的测试，都需要先执行登录操作。我们可以创建一个loggedInPageFixture，它继承自原始的pageFixture，但在提供page对象之前，先自动完成登录流程。同样，测试结束后可能需要清理测试产生的临时文件、删除数据库中的测试记录等。这些清理逻辑也应该封装在 Fixture 的生命周期中。

2.4 复杂依赖关系的管理

有些测试资源存在依赖关系。比如，创建一个订单（order）需要先有一个商品（product）和一个用户（user）。如果 Fixture 之间能声明依赖，Playwright 会自动按正确的顺序初始化和注入它们，这比在测试用例里手动管理要可靠得多。

2.5 并行测试下的数据隔离

当使用test.describe.configure({ mode: 'parallel' })开启并行测试时，最大的挑战就是数据竞争和污染。如果多个测试用例同时操作同一个测试账号或同一条数据，结果将不可预测。自定义 Fixtures 需要有能力为每个并行运行的 Worker 进程创建完全独立的数据副本或命名空间，确保测试的独立性。

3. Playwright Fixtures 机制深度剖析

要玩转自定义 Fixtures，必须吃透它的工作原理。这不仅仅是语法，更是一种设计模式。

3.1 Fixtures 的生命周期：不止于 Setup 和 Teardown

很多人把 Fixture 简单理解为beforeEach和afterEach的替代品，这低估了它。Playwright Test 的 Fixture 生命周期更加精细和强大：

1. 声明阶段：在test.extend或配置文件中定义 Fixture。这里指定了它的初始值、依赖的其他 Fixtures，以及可选的async初始化函数。
2. 解析阶段：当运行一个测试用例时，Playwright 会分析该用例函数签名中请求了哪些 Fixtures，并构建出一个依赖关系图。
3. 初始化阶段：Playwright 按照依赖图的拓扑顺序，依次初始化每个 Fixture。对于async的 Fixture，会执行其初始化函数。关键点：如果一个 Fixture 被多个测试用例使用，且其作用域（Scope）是'test'（默认值），那么它为每个测试用例都会初始化一次。如果作用域是'worker'，则在整个 Worker 进程内只初始化一次，并在所有用例间共享。
4. 注入阶段：初始化后的 Fixture 值被注入到测试函数（或另一个 Fixture 的初始化函数）的参数中。
5. 清理阶段：测试（或 Worker）结束时，Playwright 会按照与初始化相反的顺序，调用 Fixture 的清理逻辑（如果定义了teardown函数）。

这个生命周期管理是由框架自动完成的，开发者只需要关注“初始化时做什么”和“清理时做什么”。

3.2 作用域（Scope）的抉择：testvsworker

这是影响测试性能和隔离性的关键设计决策。

• { scope: 'test' }：这是默认值。每个测试用例都会获得一个全新的、独立的 Fixture 实例。这提供了最强的隔离性，确保测试之间不会相互影响。适用于那些状态会被测试改变的资源，比如一个登录后的page对象（每个测试应该有自己的页面和会话），或者一个需要被修改的测试数据实体。

  test.extend<{ freshPage: Page }>({ freshPage: async ({ browser }, use) => { // 每个测试都会打开一个新页面 const context = await browser.newContext(); const page = await context.newPage(); await use(page); await context.close(); }, });

• { scope: 'worker' }：在整个 Worker 进程的生命周期内，该 Fixture 只初始化一次，然后被所有运行在该 Worker 上的测试用例共享。这可以极大地提升测试速度，特别是当初始化成本很高时（例如，启动一个独立的服务、建立一个数据库连接池、登录一个管理账号获取长期有效的 Token）。

  test.extend<{ adminToken: string }>({ adminToken: [async ({ }, use) => { // 只在整个Worker启动时获取一次管理员Token const token = await fetchAdminToken(); await use(token); // Worker结束时可能不需要特殊清理 }, { scope: 'worker' }], });

  注意：使用worker作用域时必须极度小心共享状态。确保该 Fixture 是只读的，或者其状态变化不会导致测试间干扰。例如，共享的数据库连接是可以的，但共享一个会累积操作记录的page对象就是危险的。

3.3 依赖注入与自动初始化顺序

Fixtures 可以依赖其他 Fixtures。Playwright 会自动解决这些依赖。例如：

import { test as base } from '@playwright/test'; // 1. 基础用户 Fixture interface User { id: string; name: string; } async function createUser(role: string): Promise<User> { /* ... */ } // 2. 扩展 Fixtures export const test = base.extend<{ user: User; loggedInPage: Page; }>({ // Fixture A: 创建一个测试用户，它不依赖其他自定义Fixture user: async ({ }, use) => { const user = await createUser('member'); await use(user); await deleteUser(user.id); // 测试后清理 }, // Fixture B: 创建一个已登录的页面，它依赖内置的 `browser` 和自定义的 `user` loggedInPage: async ({ browser, user }, use) => { const context = await browser.newContext(); const page = await context.newPage(); // 使用 user 信息执行登录逻辑 await page.goto('/login'); await page.fill('input[name="username"]', user.name); // ... 填充密码、点击登录 await page.click('button[type="submit"]'); await page.waitForURL('/dashboard'); // 等待登录成功 // 将准备好的 page 注入测试 await use(page); // 测试结束后关闭上下文 await context.close(); }, });

在上面的例子中，当测试请求loggedInPage时，Playwright 知道它需要browser和user。它会先初始化user（因为它没有其他自定义依赖），然后初始化browser（内置 Fixture），最后才初始化loggedInPage。这种声明式的依赖管理让代码组织非常清晰。

4. 实战：构建测试数据注入 Fixture

理论讲完了，我们来点实际的。构建一个健壮的数据注入 Fixture，需要考虑创建、使用、清理的全流程。

4.1 设计一个可配置的商品数据 Fixture

假设我们有一个电商项目，很多测试都需要一个“可购买的商品”。这个商品应该有不同的属性变体（如价格、库存），并且测试后需要清理。

// fixtures/test-data.ts import { test as base, APIRequestContext } from '@playwright/test'; import { v4 as uuidv4 } from 'uuid'; // 定义商品接口 export interface ProductFixtureOptions { price?: number; stock?: number; category?: string; } export interface Product { id: string; name: string; price: number; stock: number; category: string; sku: string; } export const test = base.extend<{ apiContext: APIRequestContext; createProduct: Product; createProductWithOptions: [ProductFixtureOptions, Product]; }>({ // 依赖一个已配置好的 API 请求上下文（假设已在全局 setup 中配置好认证信息） apiContext: async ({ }, use) => { // 这里简化处理，实际项目中可能从环境变量读取 baseURL 和 token const context = await request.newContext({ baseURL: process.env.API_BASE_URL, extraHTTPHeaders: { 'Authorization': `Bearer ${process.env.API_TOKEN}`, }, }); await use(context); await context.dispose(); }, // 默认商品 Fixture createProduct: async ({ apiContext }, use) => { const productId = `test-prod-${uuidv4().substring(0, 8)}`; const productName = `测试商品-${productId}`; // 调用后端 API 创建商品 const response = await apiContext.post('/api/products', { data: { id: productId, name: productName, price: 99.9, stock: 100, category: 'electronics', sku: `SKU-${productId}`, } }); if (!response.ok()) { throw new Error(`Failed to create test product: ${await response.text()}`); } const product: Product = await response.json(); // 将商品对象注入测试 await use(product); // 测试后清理：删除商品 console.log(`Cleaning up product: ${product.id}`); const deleteRes = await apiContext.delete(`/api/products/${product.id}`); if (!deleteRes.ok() && deleteRes.status() !== 404) { // 404 表示可能已被其他流程删除，可忽略 console.error(`Failed to delete test product ${product.id}: ${await deleteRes.text()}`); } }, // 带参数的商品 Fixture (使用 tuple 模式) createProductWithOptions: async ({ apiContext }, use, testInfo) => { const createdProducts: Product[] = []; // 这个 Fixture 的初始化函数接收一个 `options` 参数和一个 `use` 回调 await use(async (options: ProductFixtureOptions = {}) => { const productId = `test-prod-opt-${uuidv4().substring(0, 8)}`; const productName = `测试商品(定制)-${productId}`; const productData = { id: productId, name: productName, price: options.price ?? 199.9, // 默认值 stock: options.stock ?? 50, category: options.category ?? 'books', sku: `SKU-OPT-${productId}`, }; const response = await apiContext.post('/api/products', { data: productData }); if (!response.ok()) { throw new Error(`Failed to create custom product: ${await response.text()}`); } const product: Product = await response.json(); createdProducts.push(product); // 记录以便后续清理 return product; }); // 测试后清理所有通过此 Fixture 创建的商品 console.log(`Cleaning up ${createdProducts.length} custom products for test: ${testInfo.title}`); for (const product of createdProducts) { const deleteRes = await apiContext.delete(`/api/products/${product.id}`); if (!deleteRes.ok() && deleteRes.status() !== 404) { console.error(`Failed to delete custom product ${product.id}`); } } }, });

关键点解析：

1. 使用 Tuple 模式实现可配置 Fixture：createProductWithOptions的定义[ProductFixtureOptions, Product]是一个 Playwright Fixture 的特殊语法。它表示这个 Fixture 是一个工厂函数，测试中调用时会传入options参数，并返回一个Product。这比定义多个类似 Fixture（如createExpensiveProduct,createOutOfStockProduct）更灵活。
2. 依赖内置或其它 Fixture：我们的数据 Fixture 依赖于apiContext，这确保了创建和删除商品都使用正确的 API 端点和认证信息。
3. 可靠的清理机制：在use回调执行后（即测试函数运行完毕），我们执行清理逻辑。即使测试失败，清理逻辑也会被执行（除非整个进程崩溃）。使用uuid生成唯一 ID 可以避免名称冲突。清理时对 404 状态码的容忍也很重要，因为商品可能已被测试用例本身删除。
4. 错误处理：对 API 请求进行状态检查，并在失败时抛出有意义的错误，有助于快速定位问题。

4.2 在测试中使用数据 Fixture

// tests/order.spec.ts import { test, expect } from '../fixtures/test-data'; // 导入我们扩展过的 test test('用户使用默认商品下单', async ({ page, createProduct }) => { // createProduct 已自动创建并注入 await page.goto(`/product/${createProduct.id}`); await expect(page.locator('.product-title')).toHaveText(createProduct.name); await page.click('button:has-text("加入购物车")'); // ... 后续下单断言 }); test('用户购买特价商品', async ({ page, createProductWithOptions }) => { // 调用工厂函数，传入自定义参数 const specialProduct = await createProductWithOptions({ price: 1.0, category: 'promotion' }); await page.goto(`/product/${specialProduct.id}`); await expect(page.locator('.price')).toHaveText('$1.00'); // 测试结束后，specialProduct 会被自动清理 }); test('验证库存检查功能', async ({ page, createProductWithOptions }) => { const outOfStockProduct = await createProductWithOptions({ stock: 0 }); await page.goto(`/product/${outOfStockProduct.id}`); await expect(page.locator('button:has-text("购买")')).toBeDisabled(); await expect(page.locator('.stock-status')).toHaveText('已售罄'); });

通过这种方式，测试用例变得极其简洁和专注。数据创建和清理的复杂性被完全隐藏在了 Fixture 背后。

5. 实战：实现环境隔离与配置管理

测试环境的管理是另一个重要课题。我们不应该在测试代码中硬编码环境相关的配置。

5.1 创建环境感知的 Fixture

我们可以创建一个根级别的 Fixture 来管理环境配置，并让其他 Fixture 依赖它。

// fixtures/environment.ts import { test as base, Page, BrowserContext, APIRequestContext, request } from '@playwright/test'; import * as dotenv from 'dotenv'; import path from 'path'; // 加载环境变量，支持 .env.[environment] 文件 const env = process.env.TEST_ENV || 'staging'; dotenv.config({ path: path.resolve(__dirname, `../.env.${env}`) }); // 定义环境配置接口 export interface EnvironmentConfig { name: string; webBaseURL: string; apiBaseURL: string; adminUser: { username: string; password: string }; databaseConfig?: { host: string; port: number }; // 示例 } // 环境配置映射 const ENV_CONFIGS: Record<string, EnvironmentConfig> = { local: { name: '本地开发环境', webBaseURL: 'http://localhost:3000', apiBaseURL: 'http://localhost:8080/api', adminUser: { username: 'admin@local.com', password: 'local-admin-pass' }, }, staging: { name: '预发布环境', webBaseURL: 'https://staging.example.com', apiBaseURL: 'https://api.staging.example.com', adminUser: { username: process.env.STAGING_ADMIN_USER!, password: process.env.STAGING_ADMIN_PASS! }, }, production: { // 通常不直接测试生产环境，这里仅为示例 name: '生产环境', webBaseURL: 'https://example.com', apiBaseURL: 'https://api.example.com', adminUser: { username: process.env.PROD_ADMIN_USER!, password: process.env.PROD_ADMIN_PASS! }, }, }; export const test = base.extend<{ config: EnvironmentConfig; authenticatedApiContext: APIRequestContext; authenticatedPage: Page; }>({ // 核心：环境配置 Fixture，worker 作用域，因为配置在运行时不会改变 config: [async ({ }, use) => { const config = ENV_CONFIGS[env]; if (!config) { throw new Error(`未找到环境 '${env}' 的配置。请检查 TEST_ENV 变量或配置文件。`); } console.log(`运行测试环境: ${config.name} (${env})`); await use(config); }, { scope: 'worker' }], // 重要：整个worker共享同一配置 // 依赖 config 创建已认证的 API 上下文 authenticatedApiContext: async ({ config }, use) => { // 这里模拟获取认证token，实际可能是登录接口 const loginResponse = await request.post(`${config.apiBaseURL}/auth/login`, { data: config.adminUser, }); const { token } = await loginResponse.json(); const apiContext = await request.newContext({ baseURL: config.apiBaseURL, extraHTTPHeaders: { 'Authorization': `Bearer ${token}`, 'Content-Type': 'application/json', }, }); await use(apiContext); await apiContext.dispose(); }, // 依赖 config 创建已登录的 Page 对象 authenticatedPage: async ({ browser, config }, use) => { const context = await browser.newContext({ baseURL: config.webBaseURL, // 为所有相对URL设置基础 storageState: undefined, // 初始无状态 }); const page = await context.newPage(); // 执行UI登录 await page.goto('/login'); await page.fill('input[name="email"]', config.adminUser.username); await page.fill('input[name="password"]', config.adminUser.password); await page.click('button[type="submit"]'); await page.waitForURL('/dashboard'); // 等待登录成功跳转 // 可选：保存登录状态，供后续测试快速复用（注意隔离性） // await context.storageState({ path: `state/${env}_admin_auth.json` }); await use(page); await context.close(); }, });

5.2 在项目中使用环境隔离 Fixture

现在，你的测试文件可以完全与环境细节解耦。

// tests/admin-dashboard.spec.ts import { test, expect } from '../fixtures/environment'; test('管理员可以查看仪表盘', async ({ authenticatedPage, config }) => { // authenticatedPage 已经是在正确环境（如staging）且已登录的页面 // config 提供了当前环境的元信息 await authenticatedPage.goto('/admin/dashboard'); await expect(authenticatedPage).toHaveTitle(/仪表盘/); // 你甚至可以在断言中使用 config.name await expect(authenticatedPage.locator('.env-badge')).toContainText(config.name); }); test('通过API管理用户', async ({ authenticatedApiContext }) => { const usersResponse = await authenticatedApiContext.get('/admin/users'); expect(usersResponse.ok()).toBeTruthy(); const users = await usersResponse.json(); expect(Array.isArray(users)).toBeTruthy(); });

切换环境变得极其简单：只需在运行测试前设置TEST_ENV环境变量。

# 测试预发布环境 TEST_ENV=staging npx playwright test # 测试本地环境 TEST_ENV=local npx playwright test

这种模式将环境配置集中管理，避免了配置散落在代码各处，极大提升了测试套件的可维护性和可移植性。

6. 高级模式与组合技巧

掌握了基础的数据和环境 Fixture 后，我们可以探索一些更高级的组合使用模式。

6.1 Fixture 重写与覆盖

有时，你可能想在某一个测试文件或describe块中，临时改变某个 Fixture 的行为。Playwright 允许你重写（Override）Fixture。

// 基础 fixtures import { test as base } from '@playwright/test'; const test = base.extend<{ userRole: string; welcomeMessage: string; }>({ userRole: 'member', welcomeMessage: async ({ userRole }, use) => { const message = `Hello, ${userRole}!`; await use(message); }, }); // 在某个测试套件中重写 userRole，从而间接改变 welcomeMessage test.describe('Admin Suite', () => { // 重写 userRole Fixture test.use({ userRole: 'administrator' }); test('admin sees special welcome', async ({ welcomeMessage }) => { // 因为 userRole 被重写为 'administrator'，所以 welcomeMessage 会是 "Hello, administrator!" console.log(welcomeMessage); // 输出: Hello, administrator! expect(welcomeMessage).toContain('administrator'); }); }); // 这个测试仍然使用默认的 'member' 角色 test('member sees normal welcome', async ({ welcomeMessage }) => { expect(welcomeMessage).toBe('Hello, member!'); });

这个特性非常强大，可以让你轻松创建针对不同用户角色、不同功能模块的测试套件，而无需复制大量代码。

6.2 基于 Tag 的条件化 Fixture

你可以结合 Playwright 的testInfo对象和测试标签（Tags），让 Fixture 的行为根据测试的标签动态变化。

// fixtures/conditional-fixtures.ts import { test as base, TestInfo } from '@playwright/test'; export const test = base.extend<{ dataCleanupLevel: 'full' | 'minimal'; testData: any; }>({ dataCleanupLevel: async ({ }, use, testInfo: TestInfo) => { // 根据测试标签决定清理级别 let level: 'full' | 'minimal' = 'full'; // 默认完全清理 if (testInfo.tags.includes('persist-data')) { level = 'minimal'; // 如果测试标记为 'persist-data'，则最小化清理（可能用于调试） console.log(`Test ${testInfo.title} 使用最小化数据清理策略。`); } await use(level); }, testData: async ({ dataCleanupLevel }, use) => { const data = await createComplexTestData(); await use(data); // 根据清理级别执行不同的清理操作 if (dataCleanupLevel === 'full') { await deleteAllTestData(data); } else { await markDataAsTestOnly(data); // 仅做标记，不实际删除 } }, }); // 在测试中使用 test('快速冒烟测试 @smoke', async ({ testData }) => { // 这个测试没有 'persist-data' 标签，所以会使用 'full' 清理 }); test('调试订单流 @slow @persist-data', async ({ testData }) => { // 这个测试有 'persist-data' 标签，所以会使用 'minimal' 清理，数据可能被保留以供检查 });

6.3 处理并行测试的数据竞争

并行测试（mode: 'parallel'）是提升测试速度的利器，但对 Fixture 设计提出了挑战。关键在于确保每个 Worker 进程操作的数据是独立的。

策略一：使用 Worker 作用域 + 唯一标识符

test.extend<{ workerUniqueId: string; isolatedUser: User; }>({ workerUniqueId: [async ({ }, use) => { // 每个worker进程一个唯一ID const id = `worker-${process.env.TEST_WORKER_INDEX || '0'}-${uuidv4().substring(0,4)}`; await use(id); }, { scope: 'worker' }], isolatedUser: async ({ apiContext, workerUniqueId }, use) => { // 使用 workerUniqueId 来创建唯一用户名，避免跨worker冲突 const username = `user_${workerUniqueId}`; const user = await createUserViaApi(apiContext, { username }); await use(user); await deleteUserViaApi(apiContext, user.id); }, });

策略二：为每个测试创建完全独立的数据这是最安全的方式，也是默认（scope: 'test'）Fixtures 的行为。只要确保 Fixture 的创建逻辑使用了随机或唯一的信息（如 UUID），即使并行运行，数据也不会冲突。我们之前使用的uuidv4()就是出于这个目的。

重要提示：避免使用共享的、可变的全局状态。例如，一个worker作用域的 Fixture 返回一个可变的数组或对象，并被多个测试修改，这必然导致竞态条件。如果必须共享，请确保它是只读的或使用同步机制（如锁），但在测试中这通常不是好主意。

7. 常见问题、调试技巧与最佳实践

在实际项目中自定义 Fixtures，总会遇到一些坑。这里分享一些实战中积累的经验。

7.1 问题排查速查表

7.2 调试技巧

1. 使用console.log：在 Fixture 的初始化、use调用前后、清理阶段添加详细的日志，输出关键参数和状态。这是最直接的调试手段。
2. 利用testInfo：testInfo对象包含了丰富的上下文信息，如测试标题、文件路径、标签、重试次数等。你可以将它注入到 Fixture 中，用于生成唯一数据或条件逻辑。

   myFixture: async ({ }, use, testInfo) => { const uniqueData = `data-for-${testInfo.title.replace(/\s+/g, '-')}`; console.log(`Initializing for test: ${testInfo.title}`); await use(uniqueData); }

3. Playwright Test Trace 和 UI 模式：对于复杂的 UI 操作 Fixture（如loggedInPage），使用playwright test --ui在图形界面中运行测试，或者生成 Trace 文件 (await context.tracing.start())，可以直观地看到每一步操作，对于调试登录失败等问题非常有效。

7.3 最佳实践总结

1. 单一职责：一个 Fixture 只做一件事。不要创建一个既初始化数据库又登录用户还加载配置的“上帝 Fixture”。将其拆分为databaseConnection、config、authenticatedPage等多个小 Fixture，通过依赖组合。
2. 命名清晰：使用能清晰表达意图和返回类型的名称，如adminUser、emptyCart、publishedBlogPost。避免fixture1、setupData这种模糊的名字。
3. 默认使用test作用域：除非有明确的性能需求且能保证状态安全，否则优先使用默认的{ scope: 'test' }以获得最好的隔离性。
4. 始终清理：养成“有创建必有清理”的习惯。即使你认为数据无关紧要，清理也能防止测试仓库被垃圾数据填满，并避免对后续测试产生意外影响。
5. 拥抱失败：设计 Fixture 时要考虑初始化失败的情况。使用健壮的错误处理，提供清晰的错误信息，帮助快速定位是测试逻辑问题还是环境/数据准备问题。
6. 文档化复杂 Fixture：对于具有复杂行为或特定使用约束的 Fixture，在代码中添加 JSDoc 注释，说明其作用、依赖、清理行为以及任何注意事项。
7. 将 Fixtures 模块化：不要把所有 Fixtures 都堆在一个巨大的文件中。按领域或功能将其分组到不同的文件中（如fixtures/auth.ts、fixtures/ecommerce-data.ts、fixtures/environment.ts），然后在playwright.config.ts或一个入口文件中进行组合。这提高了代码的可维护性和可读性。

自定义 Fixtures 是 Playwright Test 框架中最强大的特性之一。它迫使你以更模块化、更声明式的方式思考测试的组织。初期投入一些时间设计良好的 Fixtures，会在项目规模增长时带来巨大的回报：更清晰的测试代码、更少的重复、更好的可维护性以及更稳定的测试执行。当你习惯了这种模式后，你会发现编写测试用例变成了一件更专注、更愉快的事情。