一、为什么要做vue-router mock？测试里的必要性

terry 3小时前阅读数 6 #Vue

做Vue项目测试时，不少同学会碰到要模拟vue-router的情况——比如组件里依赖路由参数、要测试导航逻辑，或者不想在测试时真的跳转页面，但vue-router mock到底该咋操作？不同测试场景（单元、组件、E2E）里有啥区别？mock完又要注意哪些坑？今天就把这些问题拆开来聊聊。

测试的核心是“测自己代码的逻辑，而非依赖的逻辑”，vue-router是外部依赖，真实运行时要处理浏览器历史、网络这些，测试时如果不mock，会有几个麻烦：

依赖外部环境，测试不稳定
比如测试一个“点击按钮跳转到/about”的逻辑，真实路由跳转要改浏览器URL，还可能因为网络、环境配置（比如history模式本地没配服务端）报错，让测试结果不可靠。
无法隔离，难覆盖所有分支
像路由守卫（beforeRouteEnter）、动态路由参数（$route.params.id）这些，真实环境里得手动改URL才能触发不同情况，mock能让我们“手动”给组件喂不同的路由状态，把所有逻辑分支都测到。
测试速度变慢
真实路由跳转涉及DOM更新、浏览器事件，单元测试本该秒级跑完，用了真实路由可能拖慢整个测试套件。

举个简单例子：有个<NavButton>组件，点击后调用this.$router.push('/contact')，如果不mock，测试时得真打开页面点按钮、看URL变没变，既麻烦又容易出错；mock后只需要检查$router.push有没有被调用，参数对不对，测试逻辑清晰又高效。

单元测试里怎么mock vue-router？基础步骤与示例

单元测试主打“小而专”，测单个组件/函数的逻辑，mock vue-router时，核心是模拟$router和$route这两个Vue实例上的属性，让组件以为自己在真实路由环境里跑。

步骤1：选测试工具，搭基础环境

常用的组合是@vue/test-utils（Vue官方测试工具库）+ jest（或Mocha、Vitest），先确保项目里装了这些依赖，然后在测试文件开头初始化Vue测试环境。

步骤2：模拟router实例，注入到组件

Vue组件里访问路由靠this.$router（做导航）和this.$route（拿参数、路径），所以mock时要给这俩做“替身”。

举个具体例子，测试一个点击跳转的组件：

<template>
  <button @click="goToAbout">去关于页</button>
</template>
<script>
export default {
  methods: {
    goToAbout() {
      this.$router.push('/about')
    }
  }
}
</script>

对应的测试用例（用Jest + @vue/test-utils）：

import { mount } from '@vue/test-utils'
import NavButton from './NavButton.vue'
describe('NavButton', () => {
  it('点击按钮时调用$router.push', () => {
    // 1. 模拟$router对象，包含push方法
    const mockRouter = {
      push: jest.fn() // 用jest.fn()追踪是否被调用
    }
    // 2. 把mockRouter注入到组件的Vue实例里
    const wrapper = mount(NavButton, {
      global: {
        mocks: {
          $router: mockRouter
        }
      }
    })
    // 3. 触发点击事件
    wrapper.find('button').trigger('click')
    // 4. 断言push方法被调用，且参数是'/about'
    expect(mockRouter.push).toHaveBeenCalledWith('/about')
  })
})

这里的关键是用mocks选项把$router替换成我们自己的模拟对象，这样组件里调用this.$router.push时，实际调用的是jest.fn()创建的模拟函数，方便断言。

步骤3：mock $route，模拟路由参数

如果组件依赖$route.params（比如详情页组件<UserDetail>要拿$route.params.id），就得给$route也做mock。

组件示例：

<template>
  <div>用户ID：{{ $route.params.id }}</div>
</template>

测试用例：

import { mount } from '@vue/test-utils'
import UserDetail from './UserDetail.vue'
describe('UserDetail', () => {
  it('正确渲染路由参数id', () => {
    const mockRoute = {
      params: {
        id: '123'
      }
    }
    const wrapper = mount(UserDetail, {
      global: {
        mocks: {
          $route: mockRoute
        }
      }
    })
    expect(wrapper.text()).toContain('用户ID：123')
  })
})

这里只要给$route模拟对应结构，组件就能拿到假的参数，测试渲染逻辑就稳了。

组件测试时，路由钩子和嵌套路由怎么mock？

组件测试比单元测试范围大一点，要考虑组件和子组件、路由钩子（比如beforeRouteEnter）这些复杂逻辑，这时候mock的难度更高，得更细致。

模拟路由钩子：beforeRouteEnter / beforeRouteUpdate

路由钩子是写在组件里的（比如beforeRouteEnter(to, from, next)），作用是导航进入组件前做权限判断、数据预载，测试这些钩子时，得模拟导航过程，触发钩子函数。

举个带beforeRouteEnter的组件：

<template>
  <div>{{ userInfo.name }}</div>
</template>
<script>
export default {
  data() {
    return {
      userInfo: {}
    }
  },
  beforeRouteEnter(to, from, next) {
    // 模拟从接口拿数据（这里简化成直接传数据）
    const mockData = { name: '小明' }
    next(vm => {
      vm.userInfo = mockData // 把数据传给组件实例vm
    })
  }
}
</script>

测试这个钩子，得模拟“导航进入组件”的过程，触发beforeRouteEnter，思路是：

用@vue/test-utils的mount渲染组件
手动调用beforeRouteEnter，传入模拟的to、from、next
检查组件数据是否被正确设置

测试用例：

import { mount } from '@vue/test-utils'
import UserDetailWithHook from './UserDetailWithHook.vue'
describe('UserDetailWithHook', () => {
  it('beforeRouteEnter正确设置userInfo', () => {
    const wrapper = mount(UserDetailWithHook)
    // 模拟beforeRouteEnter的参数
    const to = {}
    const from = {}
    const next = jest.fn(vm => {
      vm.userInfo = { name: '小明' }
    })
    // 调用组件的beforeRouteEnter钩子
    UserDetailWithHook.beforeRouteEnter(to, from, next)
    // 执行next里的回调（因为next是带vm的函数）
    next(wrapper.vm)
    // 断言数据是否设置成功
    expect(wrapper.vm.userInfo.name).toBe('小明')
    expect(wrapper.text()).toContain('小明')
  })
})

这里的关键是直接调用组件的钩子函数，因为beforeRouteEnter是组件的静态方法，能直接访问，然后通过next的回调把数据传给组件实例wrapper.vm。

嵌套路由的mock：子路由组件怎么处理？

如果有嵌套路由（比如父路由/user下有子路由/user/profile），测试父组件时，得确保子路由组件能被正确渲染，同时mock子路由的逻辑。

假设父组件<UserLayout>结构：

<template>
  <div class="user-layout">
    <router-view /> <!-- 子路由出口 -->
  </div>
</template>

子组件<UserProfile>：

<template>
  <div>用户资料页</div>
</template>

路由配置（简化）：

const routes = [
  {
    path: '/user',
    component: UserLayout,
    children: [
      { path: 'profile', component: UserProfile }
    ]
  }
]

测试父组件<UserLayout>在子路由匹配时是否渲染<UserProfile>，需要：

mock整个路由配置，让router-view能找到子组件
模拟当前路由为/user/profile，触发子路由匹配

测试用例（结合vue-router的createRouter、createMemoryHistory）：

import { mount } from '@vue/test-utils'
import { createRouter, createMemoryHistory } from 'vue-router'
import UserLayout from './UserLayout.vue'
import UserProfile from './UserProfile.vue'
describe('UserLayout', () => {
  it('匹配子路由时渲染UserProfile', async () => {
    // 1. 创建mock路由实例
    const router = createRouter({
      history: createMemoryHistory(), // 内存历史，不影响真实浏览器
      routes: [
        {
          path: '/user',
          component: UserLayout,
          children: [
            { path: 'profile', component: UserProfile }
          ]
        }
      ]
    })
    // 2. 挂载组件时，注入router
    const wrapper = mount(UserLayout, {
      global: {
        plugins: [router] // 把mock的router作为插件注入
      }
    })
    // 3. 导航到子路由
    await router.push('/user/profile')
    await wrapper.vm.$nextTick() // 等待路由更新和DOM渲染
    // 4. 断言子组件是否渲染
    expect(wrapper.findComponent(UserProfile).exists()).toBe(true)
  })
})

这里用了createRouter和createMemoryHistory来创建真实但隔离的路由实例，适合测试路由匹配、嵌套渲染这些复杂逻辑，和纯mock$router不同，这种方式更接近真实运行时的路由行为，但又不会影响外部环境。

端到端测试（E2E）里，mock vue-router要注意什么？

E2E测试（比如Cypress、Playwright）是模拟用户真实操作，从打开页面到点击、跳转全流程，这时候mock vue-router的思路和单元测试不一样——要平衡“真实”和“可控”。

什么时候需要mock？

E2E测试里，大部分情况要走真实路由，因为要测路由跳转后的页面交互、数据加载，但如果有这些场景，可能需要mock：

跳过权限校验：比如测试支付成功页，真实情况要先支付，但E2E里可以mock路由直接进入该页面。
模拟后端接口：路由跳转后会发请求拿数据，用mock拦截请求返回假数据，避免依赖真实后端。

E2E里mock路由的思路

以Cypress为例，两种常见方式：

直接导航到目标路由：利用cy.visit('/target-path')直接访问页面，跳过中间跳转，比如测试/order/success页面，不用真的走下单流程，直接访问该路由。
拦截路由守卫里的接口：如果路由进入前有beforeRouteEnter发请求，用cy.intercept()拦截请求，返回mock数据。

举个Cypress测试的例子，测试订单成功页：

// 测试文件：order_success.spec.js
describe('订单成功页', () => {
  it('直接访问路由，渲染正确内容', () => {
    // 直接访问目标路由，跳过中间步骤
    cy.visit('/order/success')
    // 断言页面元素
    cy.get('.success-title').should('contain', '订单支付成功')
  })
  it('拦截beforeRouteEnter里的接口，返回mock数据', () => {
    // 拦截路由守卫里的接口请求
    cy.intercept('GET', '/api/order/123', {
      statusCode: 200,
      body: { orderId: '123', status: 'success' }
    }).as('getOrder')
    // 访问路由，触发beforeRouteEnter里的请求
    cy.visit('/order/success')
    // 等待请求完成
    cy.wait('@getOrder')
    // 断言数据渲染
    cy.get('.order-id').should('contain', '123')
  })
})

这里的核心是E2E更关注“用户能看到什么、能做什么”，mock要服务于“让测试流程可控”，但尽量保留真实路由跳转的体验，如果完全mock路由对象，反而会让E2E测试失去意义（因为用户真实操作是要跳转页面的）。

mock vue-router时，这些坑要避开！

就算步骤对了，也可能碰到一些“玄学问题”，总结几个常见坑和解决方法：

路由模式不匹配：hash模式 vs history模式

VueRouter有hash和history两种模式，测试时如果用了createMemoryHistory（单元测试常用），模式是内存模式；但如果组件里写死了this.$router.push('/path')，而测试时路由实例是hash模式，就会出现路径不匹配（比如真实要跳#/path，但mock的是/path）。

解决方法：测试时统一路由模式，比如单元测试用createMemoryHistory，E2E用和生产一致的模式（或直接访问带hash的URL）。

动态路由参数覆盖不全

比如组件里用了$route.params.id，但测试时只mock了params，没考虑query、meta这些属性，如果组件里有$route.query.tab这样的逻辑，mock时要把整个$route对象的结构补全，避免报错。

解决方法：mock$route时，尽量模拟完整结构。

const mockRoute = {
  params: { id: '123' },
  query: { tab: 'info' },
  meta: { requiresAuth: true },
  path: '/user/123'
}

嵌套路由的`router-view`不渲染子组件

测试父组件时，就算配置了子路由，router-view也不渲染子组件，原因可能是没等路由导航完成，或者子组件没被正确注册。

解决方法：

用await router.push(...)后，加await wrapper.vm.$nextTick()等待DOM更新。
确保子组件在测试文件里被正确导入和注册（如果是全局组件，要在测试的global.components里注册）。

路由守卫里的`this`指向错误

在beforeRouteEnter里，如果用了箭头函数或者this指向不对，mock时会拿不到组件实例。

// 错误写法：箭头函数里的this不是组件实例
beforeRouteEnter: (to, from, next) => {
  this.userInfo = ... // this指向不对
}
// 正确写法：用普通函数，或者通过next(vm => { ... })传vm
beforeRouteEnter(to, from, next) {
  next(vm => {
    vm.userInfo = ... // vm是组件实例
  })
}

解决方法：路由守卫里严格用next(vm => { ... })来操作组件实例，测试时也按这个逻辑去mock。

说到底，vue-router mock的核心是「在不同测试阶段，用合适的方式隔离路由依赖，让测试既高效又真实」，单元测试主打“替身替换”，用mock对象模拟路由行为；组件测试要兼顾复杂逻辑，比如路由钩子、嵌套路由，可能需要半真实的路由实例；E2E测试则更偏向“流程可控”，用导航和接口拦截来模拟场景，只要把场景拆清楚，再避开那些模式不匹配、参数漏模拟的坑，vue-router mock其实没那么难，下次写测试时，不妨先想清楚：我要测路由的哪部分逻辑？当前测试场景适合全mock还是半真实？把这些想明白,测试用例自然就顺了～