Vue 测试：Vitest 与 Cypress

为什么需要测试框架

在现代前端开发中，代码测试已经从「可选项」变成了「必选项」。一个没有测试覆盖的项目，就像没有安全网的高空走钢丝——功能出问题的时候，你根本不知道是哪里摔下来的。

Vue 生态系统提供了两款主流的测试工具：Vitest 和 Cypress。它们服务于不同的测试场景，但常常让开发者纠结该选哪个。这篇文章会帮你理清它们的定位、优缺点，以及在不同场景下如何做出正确选择。

第一款工具：Vitest

它是什么

Vitest 是一个「单元测试」框架，专门用来测试 Vue 组件的逻辑是否正确。你可以把它理解成「组件的质检员」——它不关心界面长什么样，只关心组件内部的数据变化、函数返回值、事件触发是否按照预期工作。

为什么选择 Vitest

Vitest 最大的优势是速度快。它基于 Vite 构建工具，利用了 Vite 的即时编译和按需加载能力。传统的 Jest 测试框架每次运行都要先编译所有文件，而 Vitest 只编译实际用到的模块，启动时间可以从「喝一杯咖啡」缩短到「眨一下眼」。

另一个加分项是与 Vue 生态的深度整合。Vitest 原生支持 Vue Test Utils，这个官方工具库提供了 shallowMount、mount、find、trigger 等方法，让组件测试写起来像写业务代码一样自然。

如何集成到项目

假设你用 npm create vue@latest 创建了一个新项目，可以在终端执行以下命令：

1. 安装依赖包，打开项目根目录的终端，输入：

npm install -D vitest @vue/test-utils happy-dom @vitest/ui

2. 配置测试脚本，打开 package.json，在 scripts 区域添加：

"test": "vitest"

3. 创建配置文件，在项目根目录新建 vitest.config.js：

import { defineConfig } from 'vitest/config'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  test: {
    environment: 'happy-dom',
    include: ['**/*.spec.js', '**/*.spec.jsx', '**/*.vue']
  }
})

4. 写一个测试用例，新建 src/components/__tests__/Counter.spec.js：

import { mount } from '@vue/test-utils'
import { describe, it, expect } from 'vitest'
import Counter from '../Counter.vue'

describe('Counter 组件', () => {
  it('初始化时显示计数为 0', () => {
    const wrapper = mount(Counter)
    expect(wrapper.text()).toContain('0')
  })

  it('点击按钮后计数增加', async () => {
    const wrapper = mount(Counter)
    await wrapper.find('button').trigger('click')
    expect(wrapper.text()).toContain('1')
  })
})

5. 运行测试，在终端执行：

npm test

如果配置正确，你会看到测试通过的绿色提示。整个过程从安装到运行，不超过五分钟。

Vitest 的适用场景

Vitest 擅长测试组件的「内部逻辑」，比如：计算属性是否返回正确值、emit 事件是否携带预期参数、方法函数处理边界情况是否正常。它也适合测试 Pinia 状态管理、工具函数、Composables 这些与 UI 无关的纯逻辑代码。

第二款工具：Cypress

它是什么

Cypress 是一个「端到端测试」框架，简称 E2E 测试。它模拟真实的浏览器环境，像一个真正的用户在操作网页——点击按钮、输入表单、等待页面跳转、验证元素存在。它关注的是「用户能不能顺利完成某个任务」。

你可以把 Cypress 想象成「自动化的 QA 工程师」：它打开浏览器，逐个步骤执行你写好的测试脚本，最后告诉你「这个功能通过了」或者「这里有个 bug」。

为什么选择 Cypress

Cypress 的核心优势是可靠性高。因为它运行在真实的浏览器环境里，测试结果和用户看到的完全一致。不像单元测试可能有「测试环境正常，生产环境炸了」的风险，Cypress 测试通过就意味着功能在真实场景下也能跑通。

另一个亮点是调试体验好。Cypress 自动录制测试视频和截图，失败时会自动保存当时页面的状态。你可以直接在测试界面里「时光倒流」，查看每一步操作后的页面快照，快速定位问题。

如何集成到项目

继续使用上面的 Vue 项目，集成 Cypress 的步骤如下：

1. 安装依赖包，在终端执行：

npm install -D cypress @cypress/vue

2. 配置测试脚本，打开 package.json，添加：

"cypress:open": "cypress open",
"cypress:run": "cypress run"

3. 创建配置文件，在项目根目录新建 cypress.config.js：

import { defineConfig } from 'cypress'

export default defineConfig({
  component: {
    devServer: {
      framework: 'vue',
      bundler: 'vite'
    }
  },
  e2e: {
    baseUrl: 'http://localhost:5173'
  }
})

4. 准备测试文件，新建 cypress/support/component.js：

import { mount } from '@cypress/vue'
import { defineGlobalWin } from '@cypress/vue/dist/support'

// 让 mount 方法在所有测试文件中可用
globalThis.mount = mount

5. 写一个组件测试，新建 cypress/components/Counter.cy.js：

import Counter from '../../src/components/Counter.vue'

describe('Counter 组件', () => {
  it('显示初始计数 0', () => {
    mount(Counter)
    cy.contains('button', 'Count: 0').should('exist')
  })

  it('点击按钮后计数变为 1', () => {
    mount(Counter)
    cy.get('button').click()
    cy.contains('button', 'Count: 1').should('exist')
  })
})

6. 启动测试，在终端执行：

npm run cypress:open

Cypress 会弹出一个独立的测试窗口，展示你的测试用例列表。点击任意用例，窗口会实时播放测试执行过程，就像看视频一样直观。

Cypress 的适用场景

Cypress 适合测试「用户故事」：用户登录后能否看到欢迎页、提交表单后能否收到成功提示、从列表页点击能否跳转到详情页。它也擅长检测 UI 样式问题、异步请求超时、第三方服务集成等只有在真实环境中才会暴露的 bug。

核心差异对比

理解了两款工具的基本概念后，我们需要从多个维度看清它们的本质区别。

用一个生活场景来类比：Vitest 像是「检查每个零件是否合格」，Cypress 像是「把整车开上路遛一圈」。前者速度快、效率高，但可能漏掉零件之间的配合问题；后者覆盖面全、结果可靠，但耗时久、成本高。

实际项目中的组合策略

真正专业的 Vue 项目不会只选其中一个，而是让两款工具各司其职，形成完整的测试金字塔。

底层是单元测试，用 Vitest 覆盖所有工具函数、Composables、Pinia stores 的逻辑。这部分测试运行速度快，反馈及时，开发者提交代码前就能跑完。

中层是组件测试，同样用 Vitest 或 Cypress，验证组件在各种 props 组合下的渲染结果、事件发射、边界条件处理。这层测试能在组件合并前发现接口不兼容等问题。

顶层是关键流程测试，用 Cypress 覆盖核心用户路径：注册登录、支付下单、数据导出等高频操作。这些测试不需要覆盖所有分支，只要保证主流程畅通即可。

按照这个金字塔结构配置测试，项目的质量保障成本和开发效率能达到最佳平衡。

常见问题解答

问题一：Vitest 和 Cypress 能一起用吗？

当然可以。它们测试的目标完全不同，Vitest 测组件逻辑，Cypress 测用户流程，两者的测试代码完全可以共存于同一个项目。唯一的建议是分开存放：Vitest 用 .spec.js 后缀放在组件同级目录，Cypress 用 .cy.js 后缀放在 cypress/components 目录下。

问题二：项目不大，只用一个够吗？

如果项目是简单的内部工具，只有几个页面，可以用 Cypress 覆盖核心流程，放弃 Vitest。但如果项目有一定复杂度，建议至少保留 Vitest，因为单元测试的投入产出比最高——写几个测试用例能预防大部分低级 bug。

问题三：测试用例需要覆盖率达到 100% 吗？

不需要。追求 100% 覆盖率往往意味着要写大量「为了覆盖而覆盖」的无效测试，浪费开发时间。合理的做法是：核心业务逻辑 100% 覆盖，边缘功能 70% 以上，简单的展示组件可以不测。

问题四：Cypress 打开很慢，有没有加速方法？

有几个优化方向。第一，用 cypress run 替代 cypress open，前者只执行测试不打开界面，速度快很多。第二，配置 numTestsKeptInMemory 减少截图保存数量。第三，用 @cypress/request 库优化网络请求的 mock 方式。

选择建议

以下是不同场景下的推荐策略：

初创项目、快速迭代：先上 Vitest，保证核心逻辑稳定。等功能稳定后，针对登录、支付等关键流程补充少量 Cypress 测试。

企业级后台系统：Vitest 必装，Cypress 选装。系统业务逻辑复杂，单元测试能极大降低维护成本。Cypress 只用来测几个核心审批流程即可。

面向消费者的 ToC 产品：优先 Cypress，Vitest 可选。因为用户只关心「能不能用」，不关心「代码怎么写的」。但如果团队有写单元测试的习惯，两者都保留是最佳选择。

个人开源项目：Vitest 非必需，Cypress 可不装。开源项目重在功能实现，测试覆盖率不是用户关心的事。等项目成熟后再补测试也不迟。

写在最后

测试不是负担，而是技术债的「利息」。项目小的时候你可以不还利息，等项目大了，利滚利会压得你喘不过气。Vitest 和 Cypress 不是什么二选一的对立面，而是工具箱里不同的螺丝刀——该用十字的时候就用十字，该用一字的时候就用一字。

记住这个原则：用最低的成本，覆盖最大的风险。