用Vue Test Utils编写组件测试，这些边界情况你考虑了吗

写组件测试的时候，最让人头疼的往往不是"跑不跑得通"，而是那些看起来跑通了、实际上什么都没验证的测试。绿油油的覆盖率背后，可能藏着一堆"删掉断言也不会挂"的用例。用 Vue Test Utils 写测试，真正拉开水平差距的，是对边界情况的敏感度。

异步不只是 await nextTick

Vue 的更新是异步批处理的，这点大家都懂。但很多同学写了 await wrapper.find('button').trigger('click') 就直接断言 DOM，结果通过率忽高忽低。原因通常是组件内部还有一层异步——比如请求接口、watch 里调用了 async 方法。nextTick 只保证 Vue 的渲染队列被清空，不保证你组件里的 Promise 链走完了。

await wrapper.find('button').trigger('click')
await flushPromises() // 等组件内部所有 Promise 落地
expect(wrapper.text()).toContain('加载完成')

另外提醒一句：trigger 返回的 Promise 本身已经包含一次 nextTick，再手动 await nextTick() 往往是多余的。真正要警惕的是连续触发多次状态变更后只等了一次。

Props：不传、传 null、传空值

在 Vue 里，"不传"和"显式传 undefined"都会走 default，但传 null 不会。很多线上 bug 就藏在这儿。建议至少写三条用例覆盖：不传、传 null、传空数组或空字符串。

还有 props 的响应式更新：wrapper.setProps({ list: [] }) 之后不能立刻断言，同样需要 await。别忘了 props 更新可能连带触发 watch，进而触发事件——这时候断言的重点就变成了"触发了几次"。

emits 到底触发了几次

expect(wrapper.emitted('change')).toHaveLength(1)

比 toBeTruthy() 有用得多。组件因为 watch 加了 immediate: true，或者父子双方各调了一次，导致事件触发两次的情况非常常见，只判断"有没有"根本发现不了。emitted() 拿到的是每次触发的参数数组，断言参数比断言次数更接近真实行为。

v-model 要测"双向"

只测 modelValue 变化后 UI 更新，只覆盖了一半；另一半是用户输入后有没有 update:modelValue 派发出去。

await wrapper.find('input').setValue('hello')
expect(wrapper.emitted('update:modelValue')[0]).toEqual(['hello'])

setValue 会自动触发 input 事件并 await，比手动 trigger('input') 更接近真实输入。

Slots、provide/inject 与全局注册

测试带插槽的组件时，别忘了 shallowMount 不会渲染子组件。你要断言插槽内容真的渲染出来了，就得用 mount，或者用 slots 显式传入测试桩。provide/inject 建议在测试里显式注入假对象，而不是依赖真实父组件，否则测试会变得极其脆弱——父组件一改，子组件测试全红。全局注册的组件（比如 UI 库）用 global.plugins 或 global.stubs 明确声明，别让"本地能跑、CI 挂掉"这种事故反复发生。

定时器与卸载清理

组件里写了 setInterval、addEventListener、ResizeObserver，测试结束时清理干净了吗？建议加一条用例：wrapper.unmount() 之后断言 clearInterval 被调用过。

const spy = vi.spyOn(global, 'clearInterval')
wrapper.unmount()
expect(spy).toHaveBeenCalled()

这类测试能提早暴露内存泄漏，尤其在反复挂载卸载的单页应用里。用 vi.useFakeTimers() 时要小心和 await 混用，假定时器会拦截 setTimeout，如果代码依赖它做异步调度，记得配合 vi.advanceTimersByTimeAsync()。

Teleport、Transition 和必须真实 DOM 的场景

Teleport 的内容不在 wrapper.html() 里，得去 document.body 找。Transition 在测试环境默认不执行过渡，"动画结束后"的状态往往要直接跳过。涉及 IntersectionObserver、matchMedia、scrollIntoView 的组件，这些 API 在 jsdom 里压根不存在，提前在 setup 文件里 mock 掉，比在每个用例里打补丁优雅得多。

结语

组件测试的价值从来不是覆盖率数字，而是它能不能在你重构时给出真实反馈。上面这些边界情况，绕来绕去都在回答同一个问题：我这条断言，到底验证了什么？如果把它删掉测试依然通过，那它大概率没在干活。写测试花的时间和写组件差不多，但省下来的调试时间，通常要多得多。