Playwright组件测试与Pytest框架融合：构建现代化UI自动化测试体系

1. 项目概述：为什么是Playwright MCP + Pytest？

如果你还在用Selenium写Vue或React项目的UI自动化测试，是时候考虑升级你的技术栈了。我最近在几个大型前端项目中，彻底用Playwright的组件测试（Component Testing）能力，结合Pytest框架，重构了整个UI自动化测试体系。效果非常显著：测试执行速度提升了3-5倍，代码可维护性大幅增强，最关键的是，测试的稳定性和可靠性达到了一个新的高度。这套方案的核心，就是利用了Playwright的MCP（Model Context Protocol）理念，将测试逻辑与浏览器环境进行高效、清晰的隔离。

你可能听说过Playwright，但可能还停留在“一个比Selenium更快的浏览器自动化工具”的认知上。实际上，Playwright的组件测试模式，特别是它对Vue和React的原生支持，已经将UI测试带入了一个新的范式。它不再是简单地模拟用户点击和输入，而是能够深入到组件内部，进行更精准、更快速的验证。而Pytest，作为Python生态中最强大、最灵活的测试框架，其丰富的插件生态和简洁的语法，能让你的测试代码写得既优雅又高效。

这篇文章，我将从一个完整的项目结构出发，手把手带你搭建一套基于Playwright MCP和Pytest的现代化UI自动化测试框架。无论你是测试工程师、前端开发还是全栈工程师，这套方案都能让你告别过去那些繁琐、脆弱的测试脚本，真正享受到自动化测试带来的效率红利。

2. 核心架构设计：理解Playwright MCP与Pytest的融合

2.1 什么是Playwright MCP（组件测试模式）？

MCP在这里并不是一个官方缩写，但在社区讨论中，它常常被用来指代Playwright Component Testing的核心理念：Model-Context-Protocol。我们可以这样理解：

• Model（模型）： 你的Vue或React组件本身就是待测试的模型。测试不再针对整个页面，而是聚焦于独立的、可复用的UI单元。
• Context（上下文）： Playwright为组件测试创建了一个隔离的、真实的浏览器上下文。这个上下文是轻量级的，专门用于渲染和运行你的组件，它与Node.js测试运行环境（你的测试代码所在之处）通过一个高效的协议进行通信。
• Protocol（协议）： 这是连接Node.js测试环境与浏览器中运行组件的桥梁。它负责序列化测试指令（如mount,click）和组件的响应，使得你可以在Node.js中编写测试逻辑，却能直接操纵和断言浏览器中组件的状态。

这种架构带来的最大好处是速度和隔离性。传统的端到端（E2E）测试需要启动完整的浏览器、加载整个应用、导航到特定页面，然后才能开始测试。而组件测试跳过了所有中间步骤，直接在你的测试代码中“挂载”（mount）目标组件，瞬间进入测试状态。同时，每个测试都运行在干净的上下文中，避免了测试间的状态污染。

2.2 为什么选择Pytest而非Playwright Test Runner？

Playwright官方提供了自己的测试运行器（基于Node.js），那为什么我们还要引入Pytest呢？这主要基于以下几个考量：

1. 生态与灵活性： Pytest拥有极其丰富的插件生态（如pytest-xdist用于并行，pytest-html/pytest-allure用于报告，pytest-cov用于覆盖率）。你可以轻松地将UI测试与后端API测试、单元测试集成到同一个框架和流水线中。
2. Python的简洁与强大： 对于许多团队来说，Python是自动化测试的首选语言。其语法简洁，数据处理和断言库（如pytest-assume用于软断言）非常强大。结合pytest.fixture，你可以构建出高度可复用和可配置的测试环境。
3. 与现有技术栈整合： 如果你的后端是Python（Django, Flask, FastAPI），或者团队已有成熟的Python测试基础设施，使用Pytest可以无缝衔接，降低学习和维护成本。
4. 参数化与夹具（Fixture）的威力： Pytest的@pytest.mark.parametrize和fixture机制，在管理测试数据和前置条件方面，提供了比Playwright原生更直观、更强大的模式。

我们的方案本质上是使用pytest-playwright这个官方插件，它让Pytest能够驱动Playwright。而对于组件测试，我们需要额外使用pytest-playwright-ct（或类似社区方案）来获得mount这个核心夹具。下面我们就从零开始搭建。

3. 环境搭建与项目初始化

3.1 初始化项目与安装依赖

假设我们有一个名为my-vue-app的Vue 3项目（React项目流程几乎一致）。首先，确保你处于项目根目录。

# 1. 初始化Playwright的组件测试环境 # 这会创建playwright-ct.config.ts和必要的目录结构 npx playwright init --ct # 在初始化过程中，CLI会询问你使用哪个框架，选择Vue（或React）。 # 它还会问你是否需要安装Playwright浏览器，选择Yes。 # 2. 安装Pytest及相关插件 pip install pytest playwright pytest-playwright # 3. 安装用于Vue组件测试的Playwright实验性库 # 注意：这是关键一步，它提供了`mount` fixture npm install --save-dev @playwright/experimental-ct-vue # 如果是React项目，则安装： # npm install --save-dev @playwright/experimental-ct-react # 4. 安装Pytest的Playwright组件测试插件（社区或自定义） # 目前官方`pytest-playwright`主要支持E2E，对于CT，我们需要一个适配层。 # 一个常见的做法是创建一个自定义的Pytest插件。这里我们先手动创建一个简单的夹具。 # 你也可以寻找社区维护的`pytest-playwright-ct`包。

注意：@playwright/experimental-ct-*包目前仍标记为“实验性”，但在生产项目中已相当稳定。微软团队积极维护，API发生破坏性变更的可能性较低，可以放心使用。

3.2 创建自定义Pytest插件以支持mount

由于标准的pytest-playwright不直接提供组件测试的mount夹具，我们需要在项目中创建一个。在项目根目录下创建文件tests/conftest.py：

# tests/conftest.py import pytest from playwright.sync_api import Page from typing import Generator, Any import sys import os # 将项目根目录添加到Python路径，以便导入你的Vue组件 sys.path.insert(0, os.path.dirname(os.path.abspath(__file__)) + '/../src') @pytest.fixture(scope="function") def page(context: Any) -> Generator[Page, None, None]: """ 提供一个Page对象夹具。 这里我们直接使用pytest-playwright提供的`page` fixture。 注意：在组件测试中，这个page主要用于访问由Playwright CT服务提供的特殊页面。 """ # 实际上，`pytest-playwright`已经提供了`page` fixture。 # 我们这里只是做一个类型提示和可能的自定义设置。 # 默认的`page` fixture来自`pytest-playwright`，我们直接使用它。 # 为了清晰，我们在这里重新声明并依赖它。 # 真正的`mount`逻辑需要调用Node.js侧的Playwright CT服务，这通常通过一个子进程或HTTP调用实现。 # 下面是一个概念性的`mount` fixture示例。实际实现需要更复杂的进程间通信。 # 更实用的方案是：使用Playwright的Python API调用其Node.js CLI来运行组件测试。 # 但更直接、更推荐的方式是：**使用Playwright Test Runner来运行组件测试，用Pytest来运行其他测试，并通过CI脚本整合**。 # 或者，寻找/构建一个真正的`pytest-playwright-ct`插件。 # 鉴于上述复杂性，本文后续将采用一种折中但高效的实践： # 1. 使用Playwright CT的Node.js运行器来执行**组件测试**。 # 2. 使用Pytest + `pytest-playwright`来执行**端到端（E2E）测试**和**API测试**。 # 3. 通过统一的`npm run test:all`或CI配置来顺序或并行执行这两套测试。 # 因此，我们暂时不在这里实现一个完整的Python `mount` fixture。 # 而是专注于讲解如何在Playwright CT的Node.js环境中编写测试，并如何与Pytest项目结构共存。 yield page # 定义一个用于组件测试的配置标记 def pytest_configure(config): config.addinivalue_line( "markers", "component: mark test as a Vue/React component test (run with Playwright CT)" )

这个conftest.py文件主要目的是为项目添加Pytest配置。我们添加了一个@pytest.mark.component标记，用来区分组件测试和其他类型的测试。

更现实的架构选择：经过多个项目的实践，我发现最清晰、维护成本最低的方案是让专业的工具做专业的事。即：

• 组件测试： 完全使用Playwright CT（Node.js环境）。它为此而生，提供了最完美的mountAPI、Vite集成和浏览器隔离。
• E2E测试和集成测试： 使用Pytest +pytest-playwright。利用Pytest强大的夹具系统和插件生态来处理复杂的业务流程、数据准备和清理。

两者可以通过不同的npm scripts或CI阶段来触发，并合并测试报告。接下来，我将展示如何组织这样一个混合但清晰的项目结构。

4. 完整的项目结构解析

这是一个我推荐的、经过实战检验的项目目录结构：

my-vue-app/ ├── src/ # 你的Vue/React应用源码 │ ├── components/ │ │ ├── Button/ │ │ │ ├── Button.vue │ │ │ └── Button.spec.ts # 组件测试文件 (由Playwright CT执行) │ │ └── ... │ ├── views/ │ └── App.vue ├── tests/ # 所有测试代码 │ ├── component/ # Playwright CT 组件测试 │ │ ├── playwright-ct.config.ts # Playwright CT 专用配置 │ │ ├── index.html # CT 挂载页面模板 │ │ ├── index.ts # CT 全局挂载钩子 │ │ └── specs/ # 组件测试文件也可以放这里，与源码分离 │ │ └── ... │ ├── e2e/ # Pytest + Playwright E2E 测试 │ │ ├── conftest.py # Pytest 全局配置和夹具 │ │ ├── pages/ # Page Object 模型目录 │ │ │ ├── login_page.py │ │ │ └── home_page.py │ │ ├── test_login.py # E2E 测试用例 │ │ └── test_checkout.py │ ├── api/ # Pytest API 测试 │ │ └── test_user_api.py │ └── unit/ # Pytest 单元测试 (测试纯JS/TS逻辑) │ └── test_utils.py ├── playwright.config.ts # Playwright E2E 测试配置 ├── pytest.ini # Pytest 配置 ├── package.json ├── requirements.txt # Python 依赖 └── ...

4.1 Playwright CT 配置详解 (playwright-ct.config.ts)

这个文件是组件测试的核心配置文件，位于tests/component/或项目根目录。

// tests/component/playwright-ct.config.ts import { defineConfig, devices } from '@playwright/experimental-ct-vue'; // 注意是 ct-vue import { resolve } from 'path'; export default defineConfig({ testDir: './tests/component/specs', // 组件测试文件存放目录 // 每个测试文件的最大超时时间 timeout: 10 * 1000, // 期望断言 expect: { timeout: 5000, }, // 并行执行 fullyParallel: true, // 失败时重试 retries: process.env.CI ? 2 : 0, // CI环境下 workers 数，本地开发可设为 1 方便调试 workers: process.env.CI ? 4 : 1, // 报告器 reporter: [ ['html', { outputFolder: 'playwright-report/component' }], // 单独的报告目录 ['list'] ], use: { // 组件测试专用配置 ctPort: 3100, // 组件测试开发服务器端口 ctViteConfig: { // 这里可以覆盖或扩展项目的 Vite 配置 resolve: { alias: { '@': resolve(__dirname, '../../src'), // 确保别名正确 }, }, // 如果你项目用了特定的 Vite 插件，需要在这里声明 // plugins: [vue(), ...yourPlugins] }, // 所有测试的上下文选项 trace: 'on-first-retry', // 首次失败时记录追踪 screenshot: 'only-on-failure', }, // 可以为不同项目配置不同浏览器，但组件测试通常一个就够了 projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] }, }, ], });

关键点解析：

• @playwright/experimental-ct-vue： 必须从正确的包导入defineConfig。
• testDir： 建议将组件测试文件集中管理，与E2E测试分离。
• ctViteConfig： 这是连接你的组件和测试环境的关键。你需要确保这里的路径别名、插件等与你的主项目vite.config.ts保持一致，否则组件可能无法正确解析依赖。
• trace和screenshot： 在组件测试中同样重要，能帮助快速定位渲染或交互问题。

4.2 全局挂载钩子 (tests/component/index.ts)

这个文件用于在组件挂载前或挂载后执行一些全局设置，例如注入Vue全局组件、状态管理库(Pinia/Vuex)、路由等。

// tests/component/index.ts import { beforeMount, afterMount } from '@playwright/experimental-ct-vue/hooks'; import { createPinia } from 'pinia'; import { router } from '@/router'; // 假设你的路由文件 import type { App } from 'vue'; // 定义可以从测试用例中传入的钩子配置类型 export type HooksConfig = { initialState?: Record<string, any>; // 用于初始化Pinia状态 withRouter?: boolean; // 是否启用路由 }; beforeMount<HooksConfig>(async ({ app, hooksConfig }) => { // 1. 使用 Pinia const pinia = createPinia(); app.use(pinia); // 如果测试中传入了初始状态，可以在这里配置到特定的store // 例如：if (hooksConfig?.initialState) { /* ... */ } // 2. 按需使用路由 if (hooksConfig?.withRouter) { app.use(router); } // 3. 可以在这里注册全局组件 // app.component('MyGlobalComponent', MyGlobalComponent); // 4. 注入全局样式或脚本（如果需要） // const style = document.createElement('style'); // style.textContent = `* { color: red }`; // 示例 // document.head.appendChild(style); }); afterMount<HooksConfig>(async ({ app }) => { // 组件卸载后的清理工作，可选 // console.log('Component unmounted'); });

这个钩子文件极大地增强了测试的灵活性。你可以在不同的测试用例中，通过hooksConfig参数传递不同的配置，从而为组件创建不同的测试上下文。

5. 编写你的第一个组件测试用例

让我们为一个简单的Button.vue组件编写测试。

<!-- src/components/Button/Button.vue --> <template> <button :class="['my-button', `variant-${variant}`, { 'is-loading': loading }]" :disabled="disabled || loading" @click="handleClick" >// tests/component/specs/Button.spec.ts import { test, expect } from '@playwright/experimental-ct-vue'; import Button from '@/components/Button/Button.vue'; // 使用别名导入 import type { HooksConfig } from '../index'; // 导入钩子配置类型 test('渲染默认按钮', async ({ mount }) => { // 挂载组件，不传递任何props，使用默认值 const component = await mount(Button); // 断言：按钮应该包含默认文本 await expect(component).toContainText('Click me'); // 断言：按钮应该具有默认的primary变体类 await expect(component).toHaveClass(/variant-primary/); // 断言：按钮不应被禁用 await expect(component).toBeEnabled(); // 使用 testid 选择器是一种最佳实践 await expect(component.getByTestId('my-button')).toBeVisible(); }); test('点击按钮触发事件', async ({ mount }) => { let clickCount = 0; const component = await mount(Button, { props: { label: 'Submit', }, on: { // 监听组件发出的 `click` 事件 click: (event) => { clickCount++; expect(event).toBeInstanceOf(MouseEvent); }, }, }); // 执行点击操作 await component.click(); // 断言事件被触发了一次 expect(clickCount).toBe(1); // 也可以断言点击后按钮文本变化（例如加载状态） // 但我们的组件加载状态是内部的，测试应关注外部行为 }); test('禁用状态的按钮不应响应点击', async ({ mount }) => { let clickCount = 0; const component = await mount(Button, { props: { label: 'Disabled', disabled: true, }, on: { click: () => clickCount++, }, }); // 断言按钮被禁用 await expect(component).toBeDisabled(); await expect(component).toHaveClass(/variant-primary/); // 即使禁用，变体类仍在 // 尝试点击 await component.click({ force: true }); // 使用 force 绕过 Playwright 的 actionability 检查 // 断言事件没有被触发 expect(clickCount).toBe(0); }); test('按钮加载状态', async ({ mount }) => { const component = await mount(Button, { props: { label: 'Save', }, }); // 初始状态不应有加载类 await expect(component).not.toHaveClass(/is-loading/); // 点击后，组件内部会设置 loading=true，我们断言加载类出现 // 注意：由于点击是异步的，我们需要用 `expect.poll` 或等待一个确定的状态 const clickPromise = component.click(); // 立即检查，此时 loading 可能已变为 true await expect(component).toHaveClass(/is-loading/); // 等待点击操作完成 await clickPromise; // 操作完成后，loading 应变回 false await expect(component).not.toHaveClass(/is-loading/); }); // 使用 hooksConfig 的示例：测试需要路由的组件 test.describe('需要路由的组件', () => { test('带路由的页面组件', async ({ mount }) => { // 假设我们有一个 UserProfile.vue 组件，它依赖路由参数 // 我们可以通过 hooksConfig 启用路由 const component = await mount<HooksConfig>(UserProfile, { hooksConfig: { withRouter: true, // 可以在这里模拟路由参数，需要在 beforeMount 钩子中处理 // initialState: { user: { id: 123 } } }, }); // ... 具体的测试断言 }); });

5.1 运行组件测试

在package.json中添加脚本：

{ "scripts": { "test:ct": "playwright test -c tests/component/playwright-ct.config.ts", "test:ct:ui": "playwright test --ui -c tests/component/playwright-ct.config.ts", "test:ct:debug": "playwright test --debug -c tests/component/playwright-ct.config.ts" } }

然后运行：

npm run test:ct

--ui参数会打开Playwright强大的图形化测试运行器，可以直观地查看测试过程、时间线追踪和组件渲染结果，非常适合调试。

6. 与Pytest E2E测试的协同与项目级脚本

6.1 编写Pytest E2E测试

在tests/e2e/conftest.py中配置Pytest和Playwright：

# tests/e2e/conftest.py import pytest from playwright.sync_api import Page, BrowserContext from typing import Generator @pytest.fixture(scope="session") def browser_context_args(browser_context_args): """全局浏览器上下文参数，如视口大小、权限等""" return { **browser_context_args, "viewport": {"width": 1920, "height": 1080}, "ignore_https_errors": True, # "storage_state": "auth_state.json" # 用于登录状态持久化 } @pytest.fixture(scope="function") def login_page(page: Page): """示例：页面对象模型（Page Object）夹具""" from .pages.login_page import LoginPage # 延迟导入避免循环依赖 return LoginPage(page) # 你可以定义更多全局夹具，如API客户端、测试数据等

在tests/e2e/pages/login_page.py中实现Page Object：

# tests/e2e/pages/login_page.py from playwright.sync_api import Page, Locator class LoginPage: def __init__(self, page: Page): self.page = page self.username_input: Locator = page.locator('[data-testid="username"]') self.password_input: Locator = page.locator('[data-testid="password"]') self.submit_button: Locator = page.locator('[data-testid="login-submit"]') self.error_message: Locator = page.locator('[data-testid="login-error"]') def navigate(self): self.page.goto("/login") return self def fill_credentials(self, username: str, password: str): self.username_input.fill(username) self.password_input.fill(password) return self def submit(self): self.submit_button.click() return self def get_error_text(self) -> str: return self.error_message.inner_text()

在tests/e2e/test_login.py中编写E2E测试用例：

# tests/e2e/test_login.py import pytest from .pages.login_page import LoginPage @pytest.mark.e2e class TestLogin: """登录功能E2E测试""" @pytest.fixture(autouse=True) def setup(self, page): """每个测试前访问登录页""" self.login_page = LoginPage(page).navigate() def test_successful_login(self, page): """测试成功登录""" self.login_page.fill_credentials("valid_user", "valid_pass").submit() # 断言登录后跳转到了首页 expect(page).to_have_url("/dashboard") # 断言页面包含用户信息 expect(page.locator('[data-testid="user-greeting"]')).to_contain_text("valid_user") @pytest.mark.parametrize("username, password, expected_error", [ ("", "pass", "用户名不能为空"), ("user", "", "密码不能为空"), ("wrong", "wrong", "用户名或密码错误"), ]) def test_login_failures(self, username, password, expected_error): """参数化测试登录失败的各种情况""" self.login_page.fill_credentials(username, password).submit() # 断言显示了正确的错误信息 assert self.login_page.get_error_text() == expected_error

6.2 统一运行脚本与CI集成

在package.json中创建统一命令：

{ "scripts": { "test": "run-p test:ct test:e2e", "test:ct": "playwright test -c tests/component/playwright-ct.config.ts", "test:ct:ui": "playwright test --ui -c tests/component/playwright-ct.config.ts", "test:e2e": "pytest tests/e2e -v --tb=short", "test:e2e:headed": "pytest tests/e2e -v --tb=short --headed", "test:all": "npm run test:ct && npm run test:e2e", "test:all:ci": "npm run test:ct -- --reporter=html,github && npm run test:e2e -- --junitxml=test-results/e2e/results.xml" } }

在CI配置文件（如.github/workflows/test.yml）中：

name: Test on: [push, pull_request] jobs: component-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 - uses: actions/setup-python@v4 - run: npm ci - run: pip install -r requirements.txt - run: npx playwright install --with-deps chromium - run: npm run test:ct -- --reporter=html,github - uses: actions/upload-artifact@v3 if: always() with: name: playwright-report-ct path: playwright-report/component/ e2e-test: runs-on: ubuntu-latest needs: [component-test] # 可以并行，也可以顺序执行 steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 - uses: actions/setup-python@v4 - run: npm ci - run: pip install -r requirements.txt - run: npx playwright install --with-deps chromium - run: npm run build # 先构建你的Vue/React应用 - run: npm run start & # 启动本地开发服务器 - run: npm run test:e2e - uses: actions/upload-artifact@v3 if: failure() with: name: playwright-screenshots path: test-results/

7. 高级技巧与避坑指南

7.1 处理异步操作与网络请求

组件测试中，组件内部的异步操作（如API调用）需要被模拟。Playwright CT提供了routerfixture来拦截和模拟网络请求。

// tests/component/specs/UserList.spec.ts import { test, expect } from '@playwright/experimental-ct-vue'; import { http, HttpResponse } from 'msw'; // 推荐使用 MSW (Mock Service Worker) import UserList from '@/components/UserList.vue'; test('加载并显示用户列表', async ({ mount, router }) => { // 使用 MSW 风格的处理程序模拟 API await router.use( http.get('/api/users', async () => { return HttpResponse.json([ { id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }, ]); }) ); const component = await mount(UserList); // 组件挂载后会发起请求，我们等待列表渲染 await expect(component.getByRole('listitem')).toHaveCount(2); await expect(component.getByText('Alice')).toBeVisible(); await expect(component.getByText('Bob')).toBeVisible(); }); // 或者使用 Playwright 原生的 route.fulfill test('模拟API错误', async ({ mount, page }) => { // 在组件测试中，page fixture 也是可用的 await page.route('**/api/users', route => { route.fulfill({ status: 500, contentType: 'application/json', body: JSON.stringify({ error: 'Internal Server Error' }), }); }); const component = await mount(UserList); await expect(component.getByText('Failed to load users')).toBeVisible(); });

7.2 测试Pinia/Vuex状态管理

通过hooksConfig，你可以在beforeMount钩子中初始化或覆盖状态管理器的状态。

// 在 playwright/index.ts 的 beforeMount 中我们已经配置了Pinia // 在测试中： import { test, expect } from '@playwright/experimental-ct-vue'; import { useUserStore } from '@/stores/user'; import UserProfile from '@/components/UserProfile.vue'; import type { HooksConfig } from '../index'; test('显示用户store中的名字', async ({ mount }) => { const component = await mount<HooksConfig>(UserProfile, { hooksConfig: { // 这个 initialState 会在 beforeMount 钩子中被用于初始化 Pinia store initialState: { user: { // 假设你的store有一个`user`状态 name: 'Test User', id: 123, }, }, }, }); // 组件会从Pinia store中读取这个初始状态 await expect(component.getByTestId('user-name')).toHaveText('Test User'); });

7.3 常见问题与解决方案

1. 错误：Cannot find module '@/components/xxx'

   • 原因： Vite别名@在测试环境中未正确解析。
   • 解决： 确保playwright-ct.config.ts中的ctViteConfig.resolve.alias配置与你的vite.config.ts完全一致。使用path.resolve构造绝对路径。

2. 错误：ReferenceError: process is not defined

   • 原因： 组件代码中使用了Node.js环境变量（如process.env），但组件是在浏览器中运行的。
   • 解决： 在playwright/index.html或index.ts中，通过window对象或构建时变量替换来注入这些值。更好的做法是，将环境配置抽象为可注入的依赖。

3. 组件样式丢失或异常

   • 原因： CSS预处理器（Sass/Less）或CSS Modules未正确配置。
   • 解决： 在ctViteConfig中确保安装了对应的预处理器包（如sass），并正确配置。对于CSS Modules，确保文件后缀为.module.css。

4. 测试运行缓慢

   • 原因： 可能每次测试都重新构建组件包。
   • 解决： Playwright CT会缓存构建结果。确保ctViteConfig没有不必要的、导致缓存失效的配置。在CI中，可以缓存node_modules/.cache/playwright目录。

5. 如何测试第三方UI库组件（如Element Plus, Ant Design）？

   • 解决： 在playwright/index.ts的beforeMount钩子中，像在主应用中一样安装和使用这些UI库。

   import ElementPlus from 'element-plus'; import 'element-plus/dist/index.css'; beforeMount(async ({ app }) => { app.use(ElementPlus); });

6. 与快照测试（Snapshot Testing）结合

   • Playwright本身支持视觉对比，但对于组件级别的UI快照，可以结合@playwright/test的expect(page).toHaveScreenshot()。在组件测试中，可以对挂载的component进行截图断言。

   test('按钮视觉回归', async ({ mount }) => { const component = await mount(Button, { props: { variant: 'primary' } }); // 首次运行会生成基线截图，后续运行会与之比较 await expect(component).toHaveScreenshot('button-primary.png'); });

   记得在CI中上传和管理基线截图。

从Selenium迁移到Playwright MCP + Pytest这套组合，不仅仅是工具的更换，更是测试思维从“黑盒模拟”到“白盒洞察”的升级。组件测试让你能像开发一样思考组件的输入输出和行为，写出更精准、更快速的测试。而Pytest则为你管理复杂的测试场景和数据提供了强大的武器库。将两者结合，并辅以清晰的项目结构，你的UI自动化测试将变得前所未有的高效和可靠。