1. 项目概述：为什么我们需要认真对待 Vue Router 测试

在构建现代前端应用时，路由管理是核心骨架之一。Vue Router 作为 Vue.js 生态的官方路由解决方案，其职责远不止于在不同 URL 间切换组件。随着应用复杂度提升，路由中开始承载业务逻辑：权限控制、数据预取、动态参数解析、甚至是基于路由状态的复杂 UI 交互。这时，路由配置就从一份静态的“地图”，演变成了一个包含关键行为逻辑的“交通管制中心”。如果不对其进行测试，就等于在应用的核心流程中埋下了未知的隐患。

很多开发者，包括曾经的我，都认为路由配置是“声明式”的，无需测试。的确，一个仅包含 path 和 component 的简单路由，测试价值有限，更多是验证配置是否拼写正确。然而，一旦你开始使用 导航守卫 来拦截跳转、使用 路由元信息 来标记权限、或是通过 动态路由匹配 和 路由组件传参 来传递数据，情况就完全不同了。这些行为逻辑直接决定了用户能否看到某个页面、看到的数据是否正确，是应用健壮性的关键一环。测试它们，就是在保障用户体验和业务逻辑的底线。

本文将深入探讨 Vue Router 的测试策略，从基础的配置验证，到导航守卫的单元测试，再到通过顶层组件进行集成测试。我们会使用 Jest 和 Vue Test Utils 作为测试工具，但核心思路适用于任何测试框架。关键在于理解不同测试策略的适用场景、权衡利弊，并学会如何为你的项目选择最合适的方案。无论你是正在为庞大应用的路由逻辑头疼，还是刚刚开始为项目引入测试，相信这里的实战经验和避坑指南都能给你带来启发。

2. 测试环境搭建与基础概念澄清

在开始编写任何测试之前，一个稳定、隔离的测试环境是前提。对于 Vue Router 测试，我们需要特别注意路由实例的创建方式，以避免测试间的状态污染。

2.1 测试框架与工具选型

目前，Vue 生态中最主流的测试组合是 Jest 配合 @vue/test-utils 。Jest 提供了开箱即用的测试运行器、断言库和模拟功能，而 @vue/test-utils 则提供了用于挂载 Vue 组件并与之交互的 API。

安装核心依赖：

npm install --save-dev jest @vue/test-utils @vue/vue3-jest # 针对 Vue 3
# 或
npm install --save-dev jest @vue/test-utils vue-jest # 针对 Vue 2

此外，你还需要配置 jest.config.js ，确保它能处理 .vue 单文件组件和 ES6+ 语法。一个基础的配置会包含 transform 规则，将 .vue 和 .js 文件交给对应的处理器。

注意 ：如果你的项目使用 TypeScript，还需要安装 ts-jest 或 @babel/preset-typescript 并进行相应配置。类型安全在测试中同样重要，能提前发现许多接口不匹配的问题。

2.2 路由工厂函数：测试隔离的关键

这是 Vue Router 测试中第一个，也是最重要的一个模式。直接导出一个静态的路由实例（ new VueRouter({...}) ）在测试中会带来严重问题：所有测试用例共享同一个路由实例及其状态（如 currentRoute ）。一个测试中的 router.push() 可能会影响后续测试的预期结果，导致测试用例相互依赖、顺序敏感，最终变得脆弱且不可靠。

解决方案是导出一个 路由工厂函数 。每次在测试中需要路由时，都调用这个函数创建一个全新的实例。

改造前（问题代码）:

// router/index.js
import Vue from 'vue';
import VueRouter from 'vue-router';
import Home from '../views/Home.vue';

Vue.use(VueRouter);

const routes = [
  { path: '/', component: Home },
  // ... 其他路由
];

// 直接导出单例实例
export default new VueRouter({
  mode: 'history',
  base: process.env.BASE_URL,
  routes
});

改造后（推荐做法）:

// router/index.js
import Vue from 'vue';
import VueRouter from 'vue-router';
import Home from '../views/Home.vue';

Vue.use(VueRouter);

// 定义路由配置
const routes = [
  { path: '/', component: Home },
  // ... 其他路由
];

// 导出一个创建路由实例的函数
export function createRouter() {
  return new VueRouter({
    mode: 'history', // 测试中常用 ‘abstract’ 模式以避免依赖浏览器环境
    routes,
    // 其他配置...
  });
}

// 为了兼容现有代码，可以同时导出一个默认实例（用于主应用）
// 但测试中绝对不要导入这个，而是使用 createRouter()
export default createRouter();

在测试文件中，我们就可以这样使用：

// tests/unit/router.spec.js
import { createRouter } from '@/router';

describe('Vue Router', () => {
  let router;

  beforeEach(() => {
    // 每个测试用例运行前，创建一个全新的路由实例
    router = createRouter();
  });

  it('should navigate to home', async () => {
    await router.push('/');
    expect(router.currentRoute.path).toBe('/');
  });
});

这种模式彻底解决了状态污染问题，是进行任何严肃的路由测试的基础。

2.3 理解“抽象模式”（Abstract Mode）

在单元测试中，我们通常不希望依赖浏览器的 history API（如 window.history.pushState ）。Vue Router 提供了一个 abstract 模式，它在一个数组内部管理路由历史，完全不依赖浏览器环境。这在 Node.js 测试环境中非常有用。

在创建测试专用的路由实例时，可以显式指定模式：

export function createTestRouter() {
  return new VueRouter({
    mode: 'abstract', // 关键：使用抽象模式
    routes,
  });
}

使用 abstract 模式后，路由的跳转逻辑完全在内存中运行，测试速度更快，环境更纯净。但请注意， abstract 模式下的路由与 URL 无关，所以 window.location 不会发生变化，这通常正是单元测试所期望的。

3. 导航守卫的单元测试策略

导航守卫是路由逻辑最集中的地方，也是测试的重点和难点。守卫可以是全局的、路由独享的，或是组件内的。测试的核心思想是： 将守卫函数当作一个纯函数或接近纯函数的单元进行测试 ，尽可能隔离其与 Vue Router 实例的深度耦合。

3.1 测试全局前置守卫

假设我们有一个经典的认证守卫逻辑：未登录用户访问需授权页面时，重定向到登录页。

路由配置示例:

// router/index.js
export function createRouter() {
  const router = new VueRouter({ routes });

  router.beforeEach((to, from, next) => {
    const isAuthenticated = checkAuth(); // 假设的认证检查函数
    const requiresAuth = to.matched.some(record => record.meta.requiresAuth);

    if (requiresAuth && !isAuthenticated) {
      next('/login');
    } else {
      next();
    }
  });

  return router;
}

最直接的测试想法可能是：挂载路由，执行 router.push ，然后断言路由是否跳转到了 /login 。但这会引入异步性和路由内部状态，让测试变得复杂。更优雅的策略是 直接测试守卫函数本身 。

步骤一：解耦守卫逻辑 将守卫内的核心逻辑提取到一个独立的、可测试的函数中。

// router/guards.js
export function authenticationGuard(to, from, next) {
  const isAuthenticated = checkAuth();
  const requiresAuth = to.matched.some(record => record.meta.requiresAuth);

  if (requiresAuth && !isAuthenticated) {
    next('/login');
  } else {
    next();
  }
}

// router/index.js
import { authenticationGuard } from './guards';
router.beforeEach(authenticationGuard);

步骤二：编写单元测试 现在我们可以像测试普通函数一样测试它。关键在于模拟（mock） next 函数，并检查它是否以预期的参数被调用。

// tests/unit/guards.spec.js
import { authenticationGuard } from '@/router/guards';

// 模拟认证检查函数和路由对象
jest.mock('@/utils/auth', () => ({
  checkAuth: jest.fn()
}));
import { checkAuth } from '@/utils/auth';

describe('authenticationGuard', () => {
  let nextMock;

  beforeEach(() => {
    nextMock = jest.fn(); // 创建一个模拟的 next 函数
  });

  it('允许已认证用户访问需授权页面', () => {
    checkAuth.mockReturnValue(true); // 模拟已登录
    const to = {
      path: '/dashboard',
      matched: [{ meta: { requiresAuth: true } }]
    };

    authenticationGuard(to, {}, nextMock);

    expect(nextMock).toHaveBeenCalledWith(); // 应调用 next()，无参数
    // 等同于 expect(nextMock).toHaveBeenCalledWith(undefined);
  });

  it('将未认证用户从需授权页面重定向到登录页', () => {
    checkAuth.mockReturnValue(false); // 模拟未登录
    const to = {
      path: '/dashboard',
      matched: [{ meta: { requiresAuth: true } }]
    };

    authenticationGuard(to, {}, nextMock);

    expect(nextMock).toHaveBeenCalledWith('/login'); // 应调用 next('/login')
  });

  it('允许任何用户访问公开页面', () => {
    checkAuth.mockReturnValue(false); // 即使未登录
    const to = {
      path: '/about',
      matched: [{ meta: {} }] // 元信息中没有 requiresAuth
    };

    authenticationGuard(to, {}, nextMock);
    expect(nextMock).toHaveBeenCalledWith(); // 应放行
  });
});

这种方法的优势非常明显：

1. 速度快 ：不涉及 Vue 组件挂载或路由历史管理。
2. 隔离性好 ：只关注守卫自身的业务逻辑。
3. 覆盖全面 ：可以轻松模拟各种边界情况（如 checkAuth 抛出错误）。

实操心得 ：在模拟 to 和 from 路由对象时，你不需要模拟完整的 Route 对象，只需包含守卫函数实际用到的属性（如 path , matched , meta , params , query 等）。这遵循了测试中的“按需模拟”原则，让测试意图更清晰，也更健壮。

3.2 处理守卫中的异步操作

现代应用中，守卫里经常需要发起异步请求（如验证令牌有效性）。这会让守卫函数返回一个 Promise，测试时需要处理异步逻辑。

异步守卫示例:

// router/guards.js
export function asyncAuthGuard(to, from, next) {
  return checkAuthAsync().then(isValid => {
    if (to.meta.requiresAuth && !isValid) {
      next('/login');
    } else {
      next();
    }
  }).catch(() => {
    next('/error'); // 网络错误等异常情况
  });
}

异步测试写法:

// tests/unit/guards.spec.js
import { asyncAuthGuard } from '@/router/guards';

jest.mock('@/utils/auth', () => ({
  checkAuthAsync: jest.fn()
}));
import { checkAuthAsync } from '@/utils/auth';

describe('asyncAuthGuard', () => {
  let nextMock;

  beforeEach(() => {
    nextMock = jest.fn();
    jest.clearAllMocks();
  });

  it('在异步验证成功后放行', async () => {
    checkAuthAsync.mockResolvedValue(true); // 模拟一个成功的 Promise
    const to = { matched: [{ meta: { requiresAuth: true } }] };

    // 守卫返回 Promise，测试需要 await
    await asyncAuthGuard(to, {}, nextMock);

    expect(nextMock).toHaveBeenCalledWith(); // 验证放行
  });

  it('在异步验证失败后重定向', async () => {
    checkAuthAsync.mockResolvedValue(false);
    const to = { matched: [{ meta: { requiresAuth: true } }] };

    await asyncAuthGuard(to, {}, nextMock);
    expect(nextMock).toHaveBeenCalledWith('/login');
  });

  it('在异步验证抛出异常时跳转到错误页', async () => {
    checkAuthAsync.mockRejectedValue(new Error('Network Error'));
    const to = { matched: [{ meta: { requiresAuth: true } }] };

    await asyncAuthGuard(to, {}, nextMock);
    expect(nextMock).toHaveBeenCalledWith('/error');
  });
});

关键点在于使用 mockResolvedValue 和 mockRejectedValue 来模拟 Promise 的不同状态，并在测试用例中使用 async/await 。

3.3 避免 Promise 拒绝导致的测试警告

这里有一个非常隐蔽的“坑”。当你测试的守卫中执行了 next('/login') 这样的重定向，并且你的测试是通过 router.push() 来触发守卫时，Vue Router 内部可能会因为导航被中止而拒绝（reject）一个 Promise。这会在测试控制台中产生一个烦人的 "Unhandled promise rejection" 警告。

问题重现：

it('重定向未登录用户', async () => {
  const router = createTestRouter();
  // 假设 /dashboard 需要认证
  await router.push('/dashboard'); // 这里守卫会调用 next('/login')，导致 push 返回的 Promise 被拒绝
  // 测试可能通过，但控制台会有警告
});

解决方案有两种：

方案A：在测试中使用回调 API（非 Promise） Vue Router 的 push 或 replace 方法可以接受成功和失败的回调函数，从而避免返回 Promise。

it('重定向未登录用户 - 使用回调', (done) => {
  const router = createTestRouter();
  router.push('/dashboard', () => {
    /* 成功回调 */
  }, (error) => {
    // 明确处理中止错误，可在此断言 error 是否为 NavigationDuplicated 等
    expect(error).toBeDefined();
    // 主要断言：当前路由是否被重定向
    expect(router.currentRoute.path).toBe('/login');
    done(); // 通知 Jest 测试结束
  });
});

为了代码简洁，可以封装一个辅助函数：

// test/routerTestUtils.js
export function routerPush(router, location) {
  return new Promise((resolve, reject) => {
    router.push(location, resolve, reject);
  });
}

// 在测试中使用
it('重定向未登录用户 - 使用封装函数', async () => {
  const router = createTestRouter();
  try {
    await routerPush(router, '/dashboard');
  } catch (error) {
    // 预期内的导航中止错误，可以忽略或做简单断言
    expect(error).toBeDefined();
  }
  expect(router.currentRoute.path).toBe('/login');
});

方案B：捕获并静默处理拒绝的 Promise 如果你坚持使用 Promise API，可以捕获这个特定的错误。

it('重定向未登录用户 - 捕获拒绝', async () => {
  const router = createTestRouter();
  try {
    await router.push('/dashboard');
  } catch (err) {
    // 我们预期导航会被守卫中止，因此拒绝是正常的。
    // 可以可选地断言错误类型，例如 expect(err.name).toBe('NavigationDuplicated');
    // 但通常我们只关心最终路由结果。
  }
  expect(router.currentRoute.path).toBe('/login');
});

注意事项 ：我个人更倾向于 方案A 或使用封装函数。在单元测试中，我们应尽可能减少非预期的副作用（如控制台警告）。明确使用回调或封装函数，能使测试意图更清晰，即“我们正在触发一个可能被中止的导航，并关注其结果”。直接吞掉 catch 块虽然简单，但可能会掩盖其他真正的错误。

4. 通过顶层组件进行集成测试

单元测试守卫函数非常高效，但它有一个盲点：它没有验证守卫是否被正确挂载到路由实例上，也没有验证路由配置（如 component 属性）是否正确。这时，集成测试就派上用场了。一种有效的方法是通过挂载包含 <router-view> 的顶层组件（如 App.vue ）来进行测试。

4.1 测试路由组件渲染

假设我们有如下简单的 App.vue ：

<!-- App.vue -->
<template>
  <div id="app">
    <router-view />
  </div>
</template>

我们可以编写测试，验证当导航到特定路径时，正确的组件被渲染。

测试示例：

// tests/integration/app.spec.js
import { mount, createLocalVue } from '@vue/test-utils';
import VueRouter from 'vue-router';
import App from '@/App.vue';
import Home from '@/views/Home.vue';
import Login from '@/views/Login.vue';

const localVue = createLocalVue();
localVue.use(VueRouter);

describe('App.vue with Router', () => {
  let router;
  let wrapper;

  const routes = [
    { path: '/', component: Home },
    { path: '/login', component: Login }
  ];

  beforeEach(() => {
    router = new VueRouter({ mode: 'abstract', routes });
    wrapper = mount(App, {
      localVue,
      router,
    });
  });

  it('渲染 Home 组件在根路径 /', async () => {
    // 使用 setData 或 router.push 改变路由，然后等待 Vue 更新
    await router.push('/');
    // 断言 wrapper 包含了 Home 组件的某些特征
    // 例如，Home 组件有一个特定的 data-testid 或 class
    expect(wrapper.findComponent(Home).exists()).toBe(true);
    expect(wrapper.findComponent(Login).exists()).toBe(false);
  });

  it('渲染 Login 组件在 /login 路径', async () => {
    await router.push('/login');
    expect(wrapper.findComponent(Login).exists()).toBe(true);
    expect(wrapper.findComponent(Home).exists()).toBe(false);
  });
});

这种测试方法更贴近真实用户场景，它验证了从 URL 变化到最终组件渲染的完整链条。对于简单的路由配置，这能提供很高的信心。

4.2 测试路由守卫的集成效果

我们也可以将之前的认证守卫集成进来，测试整个流程。

// tests/integration/authFlow.spec.js
import { mount, createLocalVue } from '@vue/test-utils';
import VueRouter from 'vue-router';
import App from '@/App.vue';
import Dashboard from '@/views/Dashboard.vue';
import Login from '@/views/Login.vue';

// 模拟认证模块
jest.mock('@/utils/auth', () => ({
  checkAuth: jest.fn()
}));
import { checkAuth } from '@/utils/auth';

const localVue = createLocalVue();
localVue.use(VueRouter);

describe('认证流程集成测试', () => {
  let router, wrapper;

  const routes = [
    { path: '/login', component: Login },
    { path: '/dashboard', component: Dashboard, meta: { requiresAuth: true } }
  ];

  beforeEach(() => {
    // 创建带有守卫的路由
    router = new VueRouter({ mode: 'abstract', routes });
    router.beforeEach((to, from, next) => {
      if (to.matched.some(record => record.meta.requiresAuth) && !checkAuth()) {
        next('/login');
      } else {
        next();
      }
    });

    wrapper = mount(App, { localVue, router });
  });

  it('未登录用户访问 /dashboard 被重定向到 /login', async () => {
    checkAuth.mockReturnValue(false);
    // 尝试跳转到 dashboard
    await router.push('/dashboard').catch(() => {}); // 捕获预期的导航拒绝
    // 等待 Vue 更新和可能的异步导航
    await wrapper.vm.$nextTick();
    // 断言最终渲染的是 Login 组件，而不是 Dashboard
    expect(wrapper.findComponent(Login).exists()).toBe(true);
    expect(wrapper.findComponent(Dashboard).exists()).toBe(false);
    // 也可以断言当前路由路径
    expect(router.currentRoute.path).toBe('/login');
  });

  it('已登录用户可以直接访问 /dashboard', async () => {
    checkAuth.mockReturnValue(true);
    await router.push('/dashboard');
    await wrapper.vm.$nextTick();
    expect(wrapper.findComponent(Dashboard).exists()).toBe(true);
    expect(router.currentRoute.path).toBe('/dashboard');
  });
});

4.3 测试动态路由与组件传参

这是集成测试大放异彩的地方。Vue Router 允许通过 props 选项将路由参数、查询参数等作为 props 传递给组件。单元测试守卫函数无法验证这部分配置是否正确生效，而集成测试可以。

路由配置示例（布尔模式传参）:

// router/index.js
{
  path: '/user/:id',
  component: UserProfile,
  props: true // 将路由 params 中的 id 映射为组件的 id prop
}

组件测试示例:

// tests/integration/routeProps.spec.js
import { mount, createLocalVue } from '@vue/test-utils';
import VueRouter from 'vue-router';
import App from '@/App.vue';
import UserProfile from '@/views/UserProfile.vue';

const localVue = createLocalVue();
localVue.use(VueRouter);

describe('路由组件传参', () => {
  let router, wrapper;

  const routes = [
    { path: '/user/:id', component: UserProfile, props: true }
  ];

  beforeEach(() => {
    router = new VueRouter({ mode: 'abstract', routes });
    wrapper = mount(App, { localVue, router });
  });

  it('将路由参数 :id 作为 prop 传递给 UserProfile 组件', async () => {
    const testUserId = '12345';
    await router.push(`/user/${testUserId}`);
    await wrapper.vm.$nextTick();

    const userProfileComponent = wrapper.findComponent(UserProfile);
    expect(userProfileComponent.exists()).toBe(true);
    // 关键断言：检查组件是否收到了正确的 prop
    expect(userProfileComponent.props('id')).toBe(testUserId);
  });
});

这种方式直接验证了最终结果：组件是否收到了正确的数据。这比单元测试中验证 props 函数本身的返回值更有力，因为它涵盖了从路由匹配到 prop 传递的整个链路。

对于更复杂的函数模式传参：

// 路由配置
{
  path: '/search',
  component: SearchResults,
  props: (route) => ({ query: route.query.q, page: parseInt(route.query.page) || 1 })
}

集成测试同样有效：

it('将查询参数解析为 props', async () => {
  await router.push({ path: '/search', query: { q: 'vue', page: '2' } });
  await wrapper.vm.$nextTick();

  const searchResultsComponent = wrapper.findComponent(SearchResults);
  expect(searchResultsComponent.props('query')).toBe('vue');
  expect(searchResultsComponent.props('page')).toBe(2); // 注意是数字 2，不是字符串 ‘2’
});

5. 测试策略权衡与选择指南

经过前面的探讨，我们拥有了两种主要的测试武器： 守卫函数的单元测试 和 通过顶层组件的集成测试 。在实际项目中，如何选择和应用它们呢？这没有标准答案，但可以遵循一些指导原则。

5.1 单元测试 vs. 集成测试：一个对比分析

特性维度	守卫函数单元测试	顶层组件集成测试
测试焦点	守卫内部的业务逻辑（认证、权限、数据获取）。	从路由变化到组件渲染的完整流程，包括配置和传参。
测试速度	极快 。只运行 JavaScript 函数，不涉及组件挂载或虚拟 DOM。	较慢 。需要挂载 Vue 组件、创建路由实例，可能触发生命周期钩子。
隔离性	高 。通过模拟（mock）所有外部依赖，测试完全独立。	低 。依赖路由配置、组件实现，甚至其他全局状态（如 Vuex store）。
信心程度	对 逻辑正确性 信心高，但对 集成效果 信心不足。	对 端到端行为 信心高，验证了多个单元协同工作。
维护成本	低 。守卫逻辑变化时才需修改测试，不受组件重构影响。	较高 。组件或路由结构变化可能导致测试失败，即使核心逻辑未变。
适合场景	复杂的守卫逻辑、异步操作、边界条件测试。	验证路由配置、组件映射、路由参数传递是否正确。

5.2 混合策略：构建健壮的测试金字塔

最有效的方法不是二选一，而是结合两者，构建一个测试金字塔。

1. 金字塔底层（大量）：守卫函数单元测试

   • 目标 ：覆盖所有导航守卫中的业务逻辑分支（if/else）、异步状态（成功/失败/加载中）。
   • 做法 ：如第3章所述，将守卫逻辑提取为纯函数，进行彻底的单元测试。这是测试的基石，快速、稳定、反馈及时。

2. 金字塔中层（适量）：关键路由的集成测试

   • 目标 ：验证核心业务流的路由配置和守卫集成是否正常工作。
   • 做法 ：为应用中最重要的用户旅程（例如：“匿名用户登录后进入仪表盘”、“用户通过分享链接打开带参数的详情页”）编写集成测试。这些测试数量应远少于单元测试，但能提供关键的集成信心。

3. 金字塔顶层（少量）：端到端（E2E）测试

   • 目标 ：在真实浏览器环境中验证整个应用，包括路由跳转。
   • 做法 ：使用 Cypress 或 Playwright 等工具。例如，测试“点击登录按钮，跳转到仪表盘”。这超出了本文范围，但它是测试体系的重要组成部分。

具体决策流程图： 当你需要测试一个路由相关功能时，可以这样思考：

是否需要验证复杂的业务逻辑（如权限计算、数据预处理）？
    ├── 是 → 编写守卫函数的单元测试。
    └── 否 → 是否需要验证组件是否正确渲染或接收到正确的props？
        ├── 是 → 编写针对该路由的顶层组件集成测试。
        └── 否 → 这个路由行为是否极其简单（仅path->component）？
            ├── 是 → 可能无需专门测试，依赖E2E测试或手动测试即可。
            └── 否 → 考虑是否属于用户核心流程，是则补充集成测试。

5.3 实用技巧与常见陷阱

技巧1：创建可复用的测试工具函数 测试中经常需要创建路由实例、挂载组件。将这些逻辑提取到 test/utils.js 中。

// test/utils.js
import { createLocalVue, mount } from '@vue/test-utils';
import VueRouter from 'vue-router';

export function createTestRouter(routes) {
  return new VueRouter({
    mode: 'abstract',
    routes: routes || [],
  });
}

export function mountWithRouter(Component, options = {}) {
  const localVue = createLocalVue();
  localVue.use(VueRouter);
  const { routes, router } = options;
  const routerInstance = router || createTestRouter(routes);
  return mount(Component, {
    localVue,
    router: routerInstance,
    ...options,
  });
}

技巧2：谨慎对待 $route 和 $router 的模拟 在测试单个子组件（非 App.vue ）时，如果它使用了 this.$route 或 this.$router ，你需要在挂载时提供模拟对象。

// 测试一个使用了 $route.params.id 的组件
const $route = {
  params: { id: 'test-id' }
};
const wrapper = mount(MyComponent, {
  mocks: { $route }
});
expect(wrapper.text()).toContain('test-id');

但请注意，这本质上是“模拟了 Vue Router 的存在”，并没有真正测试路由。它适用于测试组件 在给定路由信息下 的渲染逻辑，而非路由行为本身。

陷阱：过度测试配置 避免为每一行简单的路由配置都编写测试。像 { path: '/about', component: About } 这样的配置，其正确性更适合通过类型检查（TypeScript）、代码审查或简单的冒烟测试来保障。为它们编写测试的投入产出比很低。

陷阱：脆弱的集成测试 集成测试因为涉及多个部分而显得脆弱。为了缓解：

• 使用 data-testid 选择器 ：在组件模板中使用 <div data-testid="user-profile"> 而非依赖类名或标签，这样即使样式或标签结构改变，测试也不会轻易失败。
• 聚焦行为，而非实现 ：断言“用户看到成功消息”，而不是“ <div class=‘alert-success’> 存在”。后者在重构 CSS 时会失败。
• 保持测试小而专注 ：一个集成测试只验证一个完整的用户场景，不要在一个测试中塞入过多步骤和断言。

6. 总结与个人实践建议

测试 Vue Router 不是一项单一任务，而是一套需要根据上下文进行选择和组合的策略。经过多个项目的实践，我个人的体会是：

从“守卫逻辑单元测试”开始总是安全的。 这是性价比最高的部分。将路由守卫中的业务逻辑抽离并充分测试，能迅速提升代码库的稳定性和可维护性。这些测试运行飞快，能给你快速反馈，非常适合在开发过程中使用测试驱动开发（TDD）。

对于核心用户流，补充“路由集成测试”。 不要为所有路由写集成测试，而是挑选那些业务价值最高、最容易出错的核心路径。例如，应用的注册-登录-主流程，或者带有复杂参数解析的详情页。这些测试能给你部署前最后的信心。

永远不要忘记“抽象模式”和“工厂函数”。 这是编写任何不脆弱的路由测试的基础。确保每个测试用例都在一个干净的路由实例上运行。

接受测试的“不完美”。 测试的目标不是 100% 的覆盖率，而是用合理的投入最大化对系统正确性的信心。有时，一个简单的、通过真实浏览器运行的端到端测试，比一堆脆弱的集成单元测试更有价值。找到适合你项目节奏和团队习惯的平衡点。

最后，记住测试的本质是服务于开发和重构的。当你发现路由测试难以编写时，这通常是一个设计信号：也许你的守卫函数过于庞大，需要拆分；也许路由配置和业务逻辑耦合过紧，需要解耦。良好的测试性往往是良好设计的一个副产品。