Vue 3项目测试体系搭建：整合Vitest、Cypress与Playwright实战指南

1. 项目概述：为什么现代前端项目需要“三驾马车”测试

最近在重构一个基于 Vue 3 的复杂后台管理系统，我再次深刻体会到，一个健壮的前端项目，其测试体系的完备性直接决定了迭代速度和线上稳定性。很多开发者，尤其是刚接触 Vue 3 生态的朋友，在用create-vue脚手架快速搭建项目后，面对琳琅满目的测试工具选项——Cypress、Playwright、Vitest——往往会感到困惑：我到底该选哪个？全都要的话，又该怎么配置才能让它们和谐共处？

这正是我们今天要解决的问题。create-vue是 Vue 官方推荐的现代化项目脚手架，它提供了清晰的选项让我们在项目初始化时就集成测试工具。但勾选之后，生成的配置文件往往只是一个起点。Cypress 用于端到端测试，模拟真实用户操作；Playwright 作为后起之秀，在多浏览器支持和性能上表现突出；Vitest 则是单元测试的利器，与 Vite 深度集成，速度快如闪电。把这“三驾马车”整合到一个项目中，意味着你的代码将拥有从单元、组件到端到端的全方位测试防护网。

我将在接下来的内容里，带你一步步完成从零开始的配置、优化，并分享我在实际项目中整合这三个框架时踩过的坑和总结出的最佳实践。无论你是想为新项目搭建坚实的测试基础，还是为老项目引入现代化的测试流程，这篇教程都能提供可直接复现的详细指南。

2. 测试框架选型与核心思路拆解

在开始动手配置之前，我们必须先理清思路：为什么是这三个工具？它们各自扮演什么角色？混用会不会带来冲突？只有想明白了这些，配置过程才会顺畅，后期的维护成本也会大大降低。

2.1 明确各框架的职责与边界

首先，我们要摒弃“一个测试框架解决所有问题”的想法。现代前端测试是分层进行的：

1. Vitest：单元/组件测试层。这是测试金字塔的底座。它的核心职责是验证单个函数、组件或模块的逻辑是否正确。得益于与 Vite 的同构，它无需打包就能直接运行你的源码，速度极快，并且完美支持 Vue 3 的 Composition API 和<script setup>语法。在create-vue项目中，它通常用于测试工具函数、Composables 和单个 Vue 组件的渲染与交互逻辑。

2. Cypress：开发者友好的端到端测试层。Cypress 的核心优势在于其出色的开发者体验和实时反馈。它的测试运行器提供了一个强大的 GUI，你可以实时看到测试步骤在浏览器中的执行情况，并且能利用cy.debug()和时光旅行调试功能快速定位问题。它非常适合用来编写和调试那些模拟关键用户路径的测试用例，例如用户登录、表单提交、页面导航等。它的设计哲学是“为开发者而生”，因此测试代码的编写和阅读都更接近开发者的思维。

3. Playwright：强大且稳定的端到端测试层。Playwright 由微软开发，它的强项在于跨浏览器支持（Chromium, Firefox, WebKit）、自动等待机制、网络拦截和丰富的设备模拟。与 Cypress 相比，Playwright 更像一个“工业级”的工具，特别适合在 CI/CD 流水线中运行大量稳定的回归测试。它可以同时启动多个浏览器进行测试，并且对现代 Web 特性的支持（如 iframe、文件上传下载）非常完善。

那么，为什么在一个项目里同时用 Cypress 和 Playwright？这并非重复建设。在我的实践中，Cypress 常用于本地开发时的快速验证和调试，而Playwright 则承担 CI 环境中的自动化回归测试任务。两者可以覆盖不同的测试场景和阶段。

2.2 项目结构设计与配置哲学

使用create-vue初始化项目时，如果你勾选了 Vitest、Cypress 和 Playwright，脚手架会为你生成基础结构。但我们需要一个更清晰、易于维护的目录结构。我推荐如下布局：

your-vue-project/ ├── src/ │ ├── components/ │ ├── views/ │ └── ... ├── tests/ │ ├── unit/ # Vitest 测试文件 │ │ ├── components/ │ │ ├── composables/ │ │ └── utils/ │ ├── e2e/ │ │ ├── cypress/ # Cypress 测试文件 │ │ │ ├── e2e/ # 测试用例 │ │ │ ├── fixtures/ │ │ │ └── support/ │ │ └── playwright/ # Playwright 测试文件 │ │ ├── tests/ # 测试用例 │ │ └── ... │ └── vitest.setup.ts # Vitest 全局设置文件 ├── cypress.config.ts ├── playwright.config.ts ├── vitest.config.ts └── ...

核心思路：将测试代码与业务代码分离，但保持清晰的对应关系。tests/unit下的结构应尽量镜像src/的结构。e2e目录下再按框架细分，避免配置和用例文件互相干扰。

注意：create-vue初始化的 Cypress 和 Playwright 目录可能都在项目根目录。我强烈建议将它们统一归置到tests/e2e/下，这能让项目根目录更干净，也符合“测试是一种独立关注点”的理念。移动后，记得更新对应的配置文件（cypress.config.ts和playwright.config.ts）中的testDir等路径设置。

2.3 依赖管理与版本协同

这是第一个容易踩坑的地方。三个框架及其相关插件版本需要兼容。使用create-vue初始化时，它会安装当时推荐的稳定版本。但如果你后续手动升级，需要留意。

• Vue 和测试工具：确保@vue/test-utils的版本与你项目中的 Vue 版本兼容。对于 Vue 3，应使用@vue/test-utils@^2.0.0。
• Cypress 组件测试：如果你要用 Cypress 测试 Vue 组件（即 Component Testing），需要安装cypress和@cypress/vue。但请注意，在整合了 Vitest 做单元/组件测试后，我个人更倾向于将组件测试的重任完全交给 Vitest，因为它的速度和与 Vite 的集成度更高。Cypress 则专注于真正的端到端测试。
• Playwright：Playwright 的安装会下载浏览器二进制文件，确保网络通畅。建议在package.json中固定@playwright/test的版本，以避免 CI 环境因版本自动升级导致的不确定性。

一个推荐的package.json依赖片段如下：

{ "devDependencies": { "vue": "^3.4.0", "@vitejs/plugin-vue": "^5.0.0", "vitest": "^1.6.0", "@vue/test-utils": "^2.4.0", "jsdom": "^24.0.0", // Vitest 可能需要，用于模拟浏览器环境 "cypress": "^13.0.0", "@cypress/vue": "^5.0.0", // 如果使用 Cypress 组件测试则保留 "@playwright/test": "^1.40.0" } }

3. 核心配置详解与实操要点

接下来，我们深入到每个工具的配置文件中，看看那些关键的配置项如何设置，以及它们之间如何协作。

3.1 Vitest 配置：速度与兼容性的平衡

create-vue生成的vitest.config.ts通常已经配置好了对 Vue 和 JSX 的支持。但我们还需要优化它以更好地适应项目。

// vitest.config.ts import { fileURLToPath, URL } from 'node:url' import { defineConfig } from 'vitest/config' import vue from '@vitejs/plugin-vue' export default defineConfig({ plugins: [vue()], resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } }, test: { // 1. 环境设置：使用 jsdom 或 happy-dom 来模拟浏览器环境 environment: 'jsdom', // 对于需要 DOM 的组件测试，这是必须的 // 2. 全局设置文件：可以在这里导入全局的测试工具、扩展断言等 setupFiles: ['./tests/vitest.setup.ts'], // 3. 覆盖率报告 coverage: { provider: 'v8', // 或 'istanbul' reporter: ['text', 'json', 'html'], exclude: [ // 排除不需要覆盖率的文件 'node_modules/', 'tests/', '**/*.d.ts', 'src/main.ts' // 通常主入口文件不写业务逻辑 ] }, // 4. 别名解析，确保测试文件中使用 '@/' 别名能正确指向 src alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) }, // 5. 针对 Vue 单文件组件的支持 globals: true, // 谨慎使用。如果设为 true，可以在测试文件中直接使用 describe, it, expect 而无需导入。但可能会引起命名冲突，我更推荐显式导入。 } })

在tests/vitest.setup.ts文件中，我们可以进行一些全局的初始化工作：

// tests/vitest.setup.ts import { config } from '@vue/test-utils' // 可选：全局配置 Vue Test Utils config.global.stubs = { // 全局存根一些常用组件，避免在测试中渲染其真实实现 Transition: false, 'TransitionGroup': false } // 可选：引入全局的匹配器，例如用于测试 DOM 的扩展 import * as matchers from '@testing-library/jest-dom/matchers' import { expect } from 'vitest' expect.extend(matchers)

实操心得：关于globals: true这个选项。虽然它很方便，但在大型项目或与多种测试工具混用时，有时会导致意外的全局变量污染。我的建议是，在测试文件的顶部显式地从vitest导入describe,it,expect,vi等。这样代码意图更清晰，也避免了潜在的冲突。你可以使用 VS Code 的片段功能来快速生成测试文件模板。

3.2 Cypress 配置：聚焦开发体验

Cypress 的配置核心在于定义基础 URL、测试文件模式以及调整浏览器行为。

// cypress.config.ts import { defineConfig } from 'cypress' import vue from '@vitejs/plugin-vue' import { fileURLToPath, URL } from 'node:url' export default defineConfig({ // 项目根目录，通常就是 Cypress 配置文件的所在目录 projectRoot: './', // 我们的测试文件放在 tests/e2e/cypress 下 fixturesFolder: 'tests/e2e/cypress/fixtures', supportFile: 'tests/e2e/cypress/support/e2e.ts', // 测试用例文件 specPattern: 'tests/e2e/cypress/e2e/**/*.cy.{js,jsx,ts,tsx}', // 视频和截图输出目录 videosFolder: 'tests/e2e/cypress/videos', screenshotsFolder: 'tests/e2e/cypress/screenshots', e2e: { // 测试运行时的基础 URL。在本地开发时，我们通常先启动开发服务器。 baseUrl: 'http://localhost:5173', // 支持 @ 别名 async setupNodeEvents(on, config) { // 这允许你在 Node 环境中运行代码，例如动态修改配置、加载插件 // 这里可以配置 Vite 插件，但通常 E2E 测试不需要 return config }, }, // 组件测试配置（如果使用）。鉴于我们主要用 Vitest，这部分可以简化或移除。 component: { devServer: { framework: 'vue', bundler: 'vite', viteConfig: { plugins: [vue()], resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } } } }, specPattern: 'src/**/*.cy.{js,jsx,ts,tsx}' // 组件测试文件通常和组件放一起 } })

在support/e2e.ts中，我们可以添加自定义命令或全局钩子：

// tests/e2e/cypress/support/e2e.ts import './commands' // 导入自定义命令 // 在每个测试文件运行前执行 beforeEach(() => { // 例如，每次测试前都访问首页，确保状态干净 cy.visit('/') }) // 自定义命令示例：快速登录 Cypress.Commands.add('login', (username = 'testUser', password = 'testPass') => { cy.visit('/login') cy.get('[data-cy="username"]').type(username) cy.get('[data-cy="password"]').type(password) cy.get('[data-cy="submit"]').click() // 断言登录成功，例如跳转到首页或出现用户菜单 cy.url().should('include', '/dashboard') })

注意事项：Cypress 的baseUrl非常重要。确保在运行 Cypress 测试前，你的开发服务器（如npm run dev）已经在这个地址上运行。你可以使用cypress open打开 GUI 运行测试，或者用cypress run在无头模式下运行。对于 CI 环境，通常使用cypress run。

3.3 Playwright 配置：为自动化与稳定性而生

Playwright 的配置更侧重于浏览器、上下文和全局设置，以适应复杂的测试场景。

// playwright.config.ts import { defineConfig, devices } from '@playwright/test' export default defineConfig({ // 测试用例目录 testDir: './tests/e2e/playwright/tests', // 并行运行测试的最大工作进程数 workers: process.env.CI ? 2 : undefined, // CI 环境限制为2，本地可更多 // 是否保留测试痕迹（失败时截图、录视频） preserveOutput: 'always', // 失败重试次数，有助于减少 flaky tests retries: process.env.CI ? 2 : 0, // 报告器 reporter: [ ['html', { outputFolder: './tests/e2e/playwright/report' }], ['list'] ], use: { // 所有测试的默认上下文选项 baseURL: 'http://localhost:5173', // 和 Cypress 保持一致 trace: 'on-first-retry', // 跟踪信息，便于调试 screenshot: 'only-on-failure', video: 'retain-on-failure', // 视口大小 viewport: { width: 1280, height: 720 }, // 忽略 HTTPS 错误（对本地开发有用） ignoreHTTPSErrors: true, }, // 项目配置：可以定义多套浏览器/设备环境 projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] }, }, { name: 'firefox', use: { ...devices['Desktop Firefox'] }, }, // 可以添加移动端模拟 // { // name: 'Mobile Chrome', // use: { ...devices['Pixel 5'] }, // }, ], // Web Server 配置：在运行测试前自动启动开发服务器 webServer: { command: 'npm run dev', // 启动开发服务器的命令 url: 'http://localhost:5173', // 等待这个 URL 返回 200 状态码 reuseExistingServer: !process.env.CI, // CI 环境不重用现有服务器 timeout: 120 * 1000, // 等待服务器启动的超时时间 }, })

Playwright 的webServer配置是一个巨大优势。它允许你在运行测试套件时，自动启动和关闭待测应用，非常适合 CI 环境。你不再需要手动在另一个终端启动服务。

在 Playwright 的测试文件中，我们通常使用 Page Object Model 模式来组织代码，以提高可维护性：

// tests/e2e/playwright/tests/login.spec.ts import { test, expect } from '@playwright/test' import { LoginPage } from '../pages/LoginPage' // 引入页面对象 test.describe('登录功能', () => { let loginPage: LoginPage test.beforeEach(async ({ page }) => { loginPage = new LoginPage(page) await loginPage.goto() }) test('使用正确凭据登录成功', async ({ page }) => { await loginPage.login('admin', 'password123') // 使用 Playwright 的自动等待，无需手动 sleep await expect(page).toHaveURL(/.*dashboard/) await expect(page.locator('text=欢迎回来，管理员')).toBeVisible() }) test('使用错误密码登录失败', async ({ page }) => { await loginPage.login('admin', 'wrong') await expect(loginPage.errorMessage).toBeVisible() await expect(loginPage.errorMessage).toContainText('密码错误') }) })

// tests/e2e/playwright/pages/LoginPage.ts import { Locator, Page } from '@playwright/test' export class LoginPage { readonly page: Page readonly usernameInput: Locator readonly passwordInput: Locator readonly submitButton: Locator readonly errorMessage: Locator constructor(page: Page) { this.page = page this.usernameInput = page.locator('[data-cy="username"]') this.passwordInput = page.locator('[data-cy="password"]') this.submitButton = page.locator('[data-cy="submit"]') this.errorMessage = page.locator('.el-alert--error') } async goto() { await this.page.goto('/login') } async login(username: string, password: string) { await this.usernameInput.fill(username) await this.passwordInput.fill(password) await this.submitButton.click() } }

踩坑记录：Playwright 的locatorAPI 非常强大，它内置了自动等待机制。这意味着当你调用locator.click()时，Playwright 会等待该元素可操作（可见、启用、稳定）。这极大地减少了测试中的sleep语句，让测试更稳定。但这也要求你的选择器必须唯一且稳定。强烈建议使用>{ "scripts": { "dev": "vite", "build": "vue-tsc && vite build", "preview": "vite preview", // Vitest 相关 "test:unit": "vitest", // 运行单元测试 "test:unit:coverage": "vitest run --coverage", // 运行并生成覆盖率报告 "test:unit:ui": "vitest --ui", // 打开 Vitest UI (需要安装 @vitest/ui) // Cypress 相关 "test:e2e:cypress": "cypress open", // 打开 Cypress GUI "test:e2e:cypress:run": "cypress run", // 无头模式运行所有 Cypress 测试 "test:e2e:cypress:run:chrome": "cypress run --browser chrome", // 指定浏览器运行 // Playwright 相关 "test:e2e:playwright": "playwright test --ui", // 打开 Playwright UI (v1.40+) "test:e2e:playwright:run": "playwright test", // 运行所有 Playwright 测试 "test:e2e:playwright:run:chromium": "playwright test --project=chromium", // 指定项目运行 "test:e2e:playwright:install": "playwright install chromium", // 安装 Chromium 浏览器 // 组合命令 "test": "npm run test:unit && npm run test:e2e:playwright:run", // 完整的测试套件，通常在 CI 中运行 "test:ci": "npm run test:unit:coverage && npm run test:e2e:playwright:run" // CI 专用，包含覆盖率 } }

4.2 环境变量与测试数据管理

测试，尤其是 E2E 测试，经常需要不同的环境配置（如测试服务器地址）和测试数据。

1. 使用.env文件：创建.env.test或.env.e2e文件，存放测试环境专用的变量。

   // .env.e2e VITE_API_BASE_URL=http://localhost:3000/api VITE_E2E_USER=test@example.com VITE_E2E_PASSWORD=secret

   在vite.config.ts中，确保能加载这些环境变量。在 Cypress 和 Playwright 的配置中，也可以通过process.env或各自的配置方式来读取。

2. 测试数据隔离与清理：这是 E2E 测试稳定性的关键。每个测试都应该从一个已知的、干净的状态开始。

   • API 拦截：利用 Playwright 的page.route()或 Cypress 的cy.intercept()拦截网络请求，返回固定的模拟数据，避免依赖不稳定的后端。
   • 数据库清理：在测试开始前或结束后，通过调用测试专用的后端 API 来清理或重置数据库。可以在 Playwright 的globalSetup或 Cypress 的before钩子中执行。
   • 本地存储清理：在测试的beforeEach钩子中，清除localStorage和sessionStorage，确保没有残留的用户会话。

4.3 CI/CD 集成配置示例（GitHub Actions）

将这套测试体系集成到 CI/CD 中是实现价值的关键。以下是一个 GitHub Actions 工作流的示例，它会在每次推送代码或发起 Pull Request 时运行完整的测试套件。

# .github/workflows/test.yml name: Test Suite on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '18' cache: 'npm' - name: Install dependencies run: npm ci # 使用 ci 命令确保依赖锁一致 - name: Run unit tests with coverage run: npm run test:unit:coverage - name: Install Playwright browsers run: npx playwright install --with-deps chromium # 只安装 CI 需要的浏览器，加快速度 - name: Build project run: npm run build # 先构建项目，确保代码能正常编译 - name: Run Playwright e2e tests run: npm run test:e2e:playwright:run env: # 传递环境变量，例如指向一个临时的测试服务器 BASE_URL: ${{ secrets.E2E_BASE_URL || 'http://localhost:4173' }} # 假设使用预览服务器 - name: Upload Playwright report if: always() # 即使测试失败也上传报告 uses: actions/upload-artifact@v4 with: name: playwright-report path: tests/e2e/playwright/report/ # playwright.config.ts 中配置的 html 报告路径 retention-days: 7 - name: Upload coverage reports uses: codecov/codecov-action@v4 with: files: ./coverage/coverage-final.json # Vitest 生成的覆盖率报告

重要提示：在 CI 中运行 Playwright 测试时，webServer配置可能不适用，因为 CI 环境通常需要先构建出静态文件，然后用一个静态文件服务器（如serve）启动，或者直接测试构建后的产物。你需要根据实际情况调整playwright.config.ts中的baseURL和webServer配置。

5. 常见问题排查与调试技巧实录

即使配置完美，在实际编写和运行测试时，你依然会遇到各种问题。这里记录了一些高频问题和我的解决思路。

5.1 Vitest 常见问题

问题1：测试文件中引入的 Vue 组件报错 “Cannot find module” 或 “Unknown file extension”。

• 原因：Vitest 基于 Vite，需要正确配置别名和插件才能解析 Vue 单文件组件。
• 解决：
  1. 确保vitest.config.ts中正确配置了resolve.alias，并且引入了@vitejs/plugin-vue。
  2. 检查导入路径是否正确。使用@/components/MyComponent而非相对路径../../components/MyComponent。
  3. 如果组件中使用了未在vite.config.ts中配置的插件（如unplugin-vue-components自动导入），需要在 Vitest 配置中也进行相应配置，或者改为在测试中手动导入组件。

问题2：测试涉及 Pinia/Vue Router 等状态/路由的组件时失败。

• 原因：测试环境没有提供这些依赖的上下文。
• 解决：在测试文件中，使用@vue/test-utils的mount或shallowMount时，通过global选项提供插件。

  import { createPinia } from 'pinia' import { mount } from '@vue/test-utils' import Component from './Component.vue' const pinia = createPinia() const wrapper = mount(Component, { global: { plugins: [pinia] } })

  对于路由，可以创建一个测试用的内存路由实例。

问题3：测试异步逻辑或定时器时不稳定。

• 原因：Vitest 默认使用原生的定时器，在快进时间时可能不准确。
• 解决：使用 Vitest 提供的vi.useFakeTimers()来模拟定时器。

  import { vi } from 'vitest' beforeEach(() => { vi.useFakeTimers() }) afterEach(() => { vi.useRealTimers() }) test('async task', async () => { const promise = someAsyncFunction() vi.advanceTimersByTime(1000) // 快进 1 秒 await expect(promise).resolves.toBe('done') })

5.2 Cypress 常见问题

问题1：测试运行时元素找不到，但手动操作页面明明存在。

• 原因：最常见的原因是 Cypress 的命令是异步的，但代码却以同步方式书写，导致命令尚未执行完毕就进行了断言或下一步操作。另一个原因是应用程序状态尚未更新（如 Vue 的响应式更新）。
• 解决：
  1. 不要赋值：Cypress 命令返回的是 Chainable 对象，不是值。避免const text = cy.get('.el').invoke('text')。
  2. 使用回调：在.then()或should()中处理结果。

     cy.get('.el').should('be.visible').then(($el) => { const text = $el.text() // 对 text 进行操作 })

  3. 等待应用状态：对于 Vue 应用，可以使用cy.wait()配合一个自定义命令，等待一个标志性的元素出现或消失，表示应用已就绪。

问题2：跨域错误或 iframe 内元素无法操作。

• 原因：Cypress 的架构限制，一个测试用例只能访问一个超级域名。
• 解决：
  1. 对于跨域，尽量避免在测试中导航到不同域名。如果必须，可以使用cy.origin()（Cypress 12.6.0+）。
  2. 对于 iframe，使用cy.frameLoaded()和cy.iframe()来定位和操作 iframe 内的元素。

     cy.frameLoaded('#my-iframe') cy.iframe('#my-iframe').find('button').click()

问题3：Cypress 在 CI 中运行失败，但在本地成功。

• 原因：CI 环境与本地环境差异（网络慢、资源少、屏幕分辨率不同）。
• 解决：
  1. 增加命令的超时时间：cy.get('.el', { timeout: 10000 })。
  2. 在 CI 配置中禁用视频录制（除非必要），以提升性能：cypress run --config video=false。
  3. 确保 CI 环境安装了所有依赖，包括 Cypress 本身（npm ci会处理）。

5.3 Playwright 常见问题

问题1：测试失败，报告 “Element is not attached to the DOM”。

• 原因：页面在操作过程中发生了重新渲染（如 Vue 组件更新），之前获取的Locator对象所指向的 DOM 元素被替换了。
• 解决：避免存储 Locator 到变量中供后续多次使用，除非你确定元素不会改变。最佳实践是在每次需要时重新获取。

  // 不推荐 const button = page.locator('button.submit') await button.click() // ... 一些操作导致页面更新 await button.click() // 可能出错！ // 推荐 await page.locator('button.submit').first().click() // ... 一些操作 await page.locator('button.submit').first().click() // 重新获取

问题2：测试在 CI 上通过，但在本地失败，或反之。

• 原因：环境差异，如浏览器版本、屏幕尺寸、网络延迟、测试数据。
• 解决：
  1. 使用固定的浏览器版本：在 CI 和本地都使用 Playwright 自带的浏览器（通过npx playwright install），确保版本一致。
  2. 统一视口和设备：在playwright.config.ts的use部分或每个测试的context中明确设置viewport。
  3. 隔离测试数据：如前所述，使用 API 拦截或前后置脚本来确保测试起点一致。
  4. 查看追踪信息：Playwright 的trace功能非常强大。在配置中启用trace: 'on-first-retry'，测试失败时会在报告中生成一个trace.zip文件。使用npx playwright show-trace trace.zip命令可以可视化地回放测试的每一步，包括网络请求、DOM 快照等，是调试的利器。

问题3：如何处理文件上传和下载？

• 解决：Playwright 对此有很好的支持。
  • 文件上传：使用setInputFiles方法。

    await page.locator('input[type="file"]').setInputFiles('path/to/my-file.jpg')

  • 文件下载：监听download事件。

    const [download] = await Promise.all([ page.waitForEvent('download'), // 等待下载开始 page.locator('button#download').click() // 触发下载 ]) const suggestedFilename = download.suggestedFilename() const path = await download.path() // 临时文件路径 // 或者保存到指定位置 await download.saveAs('/tmp/my-download.pdf')

5.4 通用调试技巧

1. 慢动作与暂停：在 Cypress 测试运行器中，你可以悬停在命令日志上查看每一步的快照。在 Playwright 中，可以在测试代码中插入await page.pause()，它会打开一个调试器，让你可以逐步执行、检查页面状态。
2. 选择性运行：Vitest 可以用it.only或describe.only只运行单个测试。Cypress 在 GUI 中可以直接点击某个测试文件运行。Playwright 可以用test.only或通过命令行npx playwright test login.spec.ts指定文件。
3. 日志输出：在测试代码中适当使用console.log。在 Playwright 中，还可以通过page.on('console', msg => console.log(msg.text()))来捕获页面中的console日志。
4. 可视化对比：对于 UI 回归测试，可以考虑集成像@playwright/test自带的截图对比功能，或者使用专门的视觉回归测试工具。

整合 Cypress、Playwright 和 Vitest 的过程，本质上是在为你的项目搭建一个多层次、自动化的质量保障体系。初期配置可能会花费一些时间，但一旦这套流程运转起来，它所带来的代码信心、回归预防和开发效率的提升是巨大的。记住，测试不是负担，而是让你能更自信、更快地交付高质量代码的利器。从为一个小功能编写第一个 Vitest 单元测试开始，逐步扩展到关键用户流程的 E2E 测试，你会很快感受到它的价值。