Vue3 全栈实战第五周：Vitest 单元测试从零搭建实战记录

目录

• 本周项目结构
• Day1的观点是，环境搭建 + Store 单元测试
• Day2的观点是，组件测试
• 说到Day3，Mock 知识储备
• 至于Day4，整合调整 + 覆盖率检查
• 常用测试 API 对比
• 本周
• 下周计划

本周项目结构

src/
stores/
mailStore.ts
mailStore.test.ts ← 新增：Store 单元测试。条用例
components/
MailItem.vue
MailItem.test.ts ← 新增：组件测试，条用例
MailSearch.vue
MailSearch.test.ts ← 新增：组件测试，条用例
MailList.vue
MailList.test.ts ← 新增：组件测试，条用例
vite.config.ts ← 修改：新增 test/coverage 配置
package.json ← 修改：新增 test、test:coverage 脚本

全周一共 条测试用例，整体语句覆盖率 %。话说回来，

从Day1来看。环境搭建 + Store 单元测试

为什么需要单元测试？至于痛点直击，

手动验证“点点点”成本高且易漏检。

• 改动一处代码可能影响到其它功能，却无法快速定位。
• 每次验证都要重复操作，浪费时间。
• 无法精确定位“哪个函数在什么输入场景下坏了”。

单元测能把验证过程写成代码。一条命令即可跑完全部，用例能精准指出失败位置。

至于环境搭建，

pnpm add -D vitest @vue/test-utils jsdom

• vitest : 测试框架本体；跑用例、断言、覆盖率统计。
• @vue/test-utils : Vue 官方工具，挂载组件、模拟交互、检查渲染结果。
• jsdom : 在 Node 环境里模拟浏览器 DOM，让 document/window 可用。

主要痛点是缺少真实浏览器时需要 jsdom 模拟，否则 @vue/test-utils/mount 无法正常工作。

vite.config.ts 里加配置:

// vite.config.ts
/// 
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
export default defineConfig({
plugins:,test: {
environment: 'jsdom',// 用 jsdom 模拟浏览器环境
globals: true,// 全局注入 describe/it/expect
}。})

package.json 加脚本：

{
"scripts":{
"test"这方面，"vitest"
}
}

基础知识点：“三件套”与痛点剖析：

// 三件套示例
describe => {
it => {
expect.toBe // assert 判断结果是否正确
})
})
// describe 可以嵌套，用来分层组织大项目的不同模块。其实，**痛点**这方面。


"断言方式"混乱导致误判。"
.

"未使用 beforeEach 重置 Pinia" 导致不同用例互相污染。"
.

"异步操作未 await" 导致假通过但实际无效。"
.
`}
`

常见断言方法区别——toBe vs toEqual——关键痛点：

expect.toEqual // 深度比较适合数组/对象
expect.toBeNull // 专门判断 null
expect).toBeUndefined // undefined 专属
// toBe 使用 === 全等比较。引用不一致会失败
expect.toBe // ❌ fail
expect.toEqual // ✅ pass
// 因为每次创建 都是新引用，要使用 toEqual 而非 toBe。**痛点**这方面，


"错误地使用了 toBe" 把一样内容却不同引用的数据判定为不等。"."
.
`}
`

beforeEach 与 Pinia 实例隔离——避免数据泄漏痛点：

describe => {
beforeEach => { setActivePinia) }) // 每个 useMailStore 都会得到新实例
})
如果不做重置。第一个用例修改了 `mails` 后第二个会看到旧数据，从而导致假通过或假失败。


异步 + await 必须——防止假通过隐患：

it => {
const store = useMailStore
await store.fetchMails // 必须 await 完整执行
expect.toBe
})
没有 `async/await` 的话。在 `fetchMails` 的 Promise 未 resolve 前就完成断言，从而得到绿灯却并未真正验证。


新增文件 src/stores/mailStore.test.ts ：示例代码与常见问题汇总：
import { describe,it,expect,beforeEach } from 'vitest'
import { setActivePinia。createPinia } from 'pinia'
import { useMailStore } from './mailStore'
describe => {
beforeEach => { setActivePinia) })
it => {
const store = useMailStore
expect.toEqual
expect.toBe
})
it => {
const store = useMailStore
const fetchPromise = store.fetchMails
expect.toBe
await fetchPromise
expect.toBe
expect.toBe
expect.toBe
})
it => {
const store = useMailStore
await store.fetchMails
const firstMail = store.mails
store.markAsRead
expect.toBe
})
/* 更多业务逻辑断言…*/
})


至于Day2，组件测试


为什么需要 @vue/test-utils？说到—痛点直击，


`mailStore.test.ts` 测的是纯逻辑，不涉及 DOM。但 `` 与 `` 等组件，需要验证渲染结果与交互事件 —— 所以必须把它们挂载成真实 DOM 并触发事件。若没有 `@vue/test-utils/mount` 就无法完成这一步。


新增文件 src/components/MailItem.test.ts ：主要代码与典型踩坑汇总：

import { describe,it,expect } from 'vitest'
import { mount } from '@vue/test-utils'
import { ref } from 'vue'
import MailItem from './MailItem.vue'
import { meModeKry } from '@/types/injectionKeys'
describe => {
const baseProps = {
再看id。'',subject: '周一例会通知',from: '',isRead: false,createdAt: new Date
}
it => {
const wrapper = mount
expect).toContain
expect).toContain
})
it => {
const wrapper = mount
const li = wrapper.find
expect).toContain
})
/* 更多场景…
*/
})

痛点评价



技巧
痛点
对策




mount
没有真实 DOM → 无法触发事件
jsdom 提供模拟


text vs find
验证文本足够。但无法检测样式或事件
用 find 获取元素再读取属性


trigger + await
点击后 Vue 更新是异步
必须 await wrapper.find.trigger


global.provide / inject
没有父组件时 inject 默认值失效
在 mount 时通过 global.provide 注入 mock 值


jsdom 转换颜色
十六进制颜色被转换为 rgb 格式
用 rgb 或者直接匹配类名 / snapshot




ts
import { describe,it,expect } from 'vitest'
import { mount } from '@vue/test-utils'
import MailSearch from './MailSearch.vue'
describe => {
it=>{ /* ... */ })
it=>{ /* ... */ })
it=>{ /* ... */ })
it=>{ /* ... */ })
it
it" 方法可被外部调用并聚焦 input',)
})

痛点评价


setValue : 快速模拟使用者输入并自动触发 input。老实说，

trigger : 模拟键盘事件。无需真正按键，

wrapper.vm : 调用 expose 的方法，如 focus。

attachTo document.body : 若想让 focus 等浏览器行为生效，需要挂载到真 DOM。



从Day3来看，Mock 知识储备


为什么需要 Mock？—现实中的困扰：


`mailApi.getList` 本地网络请求难以控制；当后端不可预知或还未上线时只能用假数据模拟请求返回，否则无法跑单测；同理路由跳转也需隔离，说起来，Mock 可以把这些外部依赖变成可追踪且可预期的假实现。让业务逻辑独立于网络状态而被彻底验证。


- vi.fn 创建假函数 – 痛点梳理 - 

ts
const mockFn = vi.fn=>{})
mockFn
expect.toHaveBeenCalled
expect.toHaveBeenCalledWith
expect.not.toHaveBeenCalledTimes
// …etc，


好处 ：记录调用次数与参数，可用于后续断言。

坏处 ：若忘记重置，会导致跨 case 泄漏。

ts
beforeEach=>{ vi.clearAllMocks;})


- vi.mock 模块级别替换 – 痛点对照 - 

ts
vi.mock{return Promise.resolve}})


替换整个模块，使所有 import 都指向 mock 实现。不过，

放在文件顶部。以保证 import 前执行。

ts
// 模拟接口失败场景：
vi.mocked?.mockRejectedValueOnce)
await expect).rejects.toThrow


- Mock 路由跳转 – 痛点方法 - 

ts
const mockPush = vi.fn
vi.mock{return{push:mockPush}}})


验证 push 是否被调用且参数正确，而不会真的跳转页面。


Day4 整合调整 + 覆盖率检查

- 覆盖率工具配置 – 痛感说明 - 
bash
pnpm add -D @vitest/coverage-v8 --save-dev
// vite.config.ts 内添加 coverage 配置:
{
test:{
environment:'jsdom'。globals:true,coverage:{
provider:'v8',reporter:,exclude:
}
}
}

注意事项


使用