随着Web应用复杂度的不断提升，自动化测试已成为保障软件质量的关键环节。在众多测试框架中，微软开源的Playwright凭借跨浏览器支持、自动等待机制和强大的API，迅速赢得了开发者的青睐。然而，许多新手在编写测试用例时，常常陷入重复初始化浏览器上下文、重复登录、重复设置测试数据的泥潭。这时，Fixtures（夹具） 便成了提升测试效率、保持代码整洁的杀手锏。本文将带您深入理解Playwright中Fixtures的使用方法，助您写出更优雅、更可靠的测试代码。

一、什么是Fixtures？为什么需要它？

在Playwright的测试体系（通常搭配@playwright/test使用）中，Fixtures是一种可复用的测试环境配置机制。简单来说，它允许你在测试用例运行前后，自动执行一些预设操作——比如启动浏览器、打开指定页面、注入身份认证信息、清理测试数据等。

传统的做法是在每个测试用例中手动调用browser.newContext()、context.newPage()，然后在测试结束时手动关闭。这会导致大量重复代码，且容易遗漏清理步骤，造成资源泄漏。Fixtures则解决了这个问题：它让测试框架自动管理资源的生命周期，你只需声明需要的fixture名称，框架就会在合适的时机初始化并在测试结束后自动销毁。

二、Playwright内置Fixtures一览

Playwright测试框架默认提供了几个开箱即用的fixture：

  • browser：每个worker进程（一个并发单元）共享同一个浏览器实例。
  • context：每个测试用例独享的浏览器上下文（相当于无痕窗口，隔离cookies、localStorage）。
  • page：每个测试用例独享的新标签页。

你可以在测试函数中直接引用它们：

import { test, expect } from '@playwright/test';

test('访问首页', async ({ page }) => {
    await page.goto('https://example.com');
    await expect(page).toHaveTitle(/Example/);
});

这里page就是一个fixture，测试框架会自动创建新页面，测试结束后自动关闭。

三、自定义Fixtures：让测试更智能

实际项目中，你往往需要更复杂的测试环境。比如，大多数页面需要用户登录后才能测试。如果每个用例都手动模拟登录流程，不仅慢，而且冗余。此时，自定义Fixture可以完美解决。

3.1 定义项目级Fixtures

在playwright.config.ts或单独的fixtures文件中，你可以通过test.extend方法扩展fixture。例如，创建一个已登录的页面fixture：

import { test as base } from '@playwright/test';
import { login } from './auth-helper';

export const test = base.extend({
    loggedInPage: async ({ page }, use) => {
        // 设置阶段：执行登录
        await page.goto('/login');
        await page.fill('#username', 'testuser');
        await page.fill('#password', 'testpass');
        await page.click('#login-btn');
        await page.waitForURL('/dashboard');
        // 将已登录页面传递给测试用例
        await use(page);
        // 清理阶段（可选）：比如退出登录或清除会话
        // 这里通常无需额外操作，因为context会自动销毁
    }
});

然后在测试中直接使用：

test('查看个人信息', async ({ loggedInPage }) => {
    await loggedInPage.goto('/profile');
    // 现在页面已经是登录状态
});

3.2 带参数的Fixtures

有时你需要根据不同场景传递参数，fixture也可以接收参数。通过返回一个工厂函数实现：

const test = base.extend({
    todoPage: async ({ page }, use) => {
        const todoPage = {
            page,
            async addTodo(text) {
                await page.fill('.todo-input', text);
                await page.press('.todo-input', 'Enter');
            },
            async getTodos() {
                return page.$$eval('.todo-item', items => items.map(i => i.textContent));
            }
        };
        await use(todoPage);
    }
});

这样，测试用例就能像使用页面对象一样，调用todoPage.addTodo('Buy milk')。

四、Fixtures的作用域与并发控制

理解fixtures的作用域对编写高效测试至关重要。Playwright支持三种作用域：

  • test（默认）：每个测试用例独享，测试之间完全隔离。
  • worker：每个Node.js工作进程共享（即所有在此进程中运行的测试）。适合重用重量级资源，如数据库连接池。
  • global：整个测试运行周期只创建一次，用于初始化全局依赖。

例如，定义一个worker级别的浏览器fixture（默认browser就是worker级别）：

const test = base.extend({
    dbConnection: [async ({}, use) => {
        const conn = await createDatabaseConnection();
        await use(conn);
        await conn.close();
    }, { scope: 'worker' }]
});

注意：作用域越大，测试之间的状态污染可能性越高，需谨慎使用。

五、实战案例：简化API测试

假设你需要测试一系列需要认证的API接口，传统做法是每个用例发送登录请求获取token。利用fixture可以一次性获取并复用：

const test = base.extend({
    authToken: [async ({ request }, use) => {
        const response = await request.post('/api/login', {
            data: { username: 'admin', password: '123456' }
        });
        const token = (await response.json()).token;
        await use(token);
    }, { scope: 'worker' }] // token在worker内共享，减少重复登录
});

test('获取数据列表', async ({ request, authToken }) => {
    const res = await request.get('/api/items', {
        headers: { Authorization: `Bearer ${authToken}` }
    });
    expect(res.status()).toBe(200);
});

六、最佳实践与注意事项

  1. 保持Fixture轻量：避免在fixture中执行耗时操作（如大量数据插入），否则会拖慢整个测试套件。考虑使用test.beforeAll替代。
  2. 明确清理责任：如果fixture创建了文件或临时数据，务必在use后的清理阶段移除。
  3. 不要过度封装：fixtures是环境配置，不是业务逻辑。过于复杂的fixture会降低测试的可读性。
  4. 利用类型安全：TypeScript用户可以为fixture添加类型注解，获得更好的IDE支持。

结语

Fixtures是Playwright测试框架中一项强大而优雅的设计，它将资源管理与测试逻辑解耦，让测试代码更简洁、更健壮。无论是简单的页面对象封装，还是复杂的多用户场景模拟，合理运用Fixtures都能显著提升测试开发效率。下次编写测试时，不妨问问自己：这个重复步骤能否提取为一个fixture？掌握它，您将离高质量自动化测试又近一步。