Vue Router测试策略：从单元测试到集成测试的完整指南 1. 项目概述为什么我们需要专门的Vue Router测试策略在Vue.js生态里路由管理是构建单页面应用SPA的核心骨架。我们花大量时间设计路由结构、配置守卫、处理动态参数但往往在测试环节路由逻辑却成了“黑盒”——只在浏览器里手动点几下确认跳转“看起来”正常就完事了。这种粗放的验证方式在项目迭代、重构或团队协作时会埋下巨大的隐患。一个看似简单的路由参数变更可能导致某个深层页面直接白屏一个导航守卫的逻辑调整可能让整个用户认证流程崩溃。因此“Vue Router Testing Strategies”这个主题探讨的远不止是“如何写测试”而是如何为应用的核心导航逻辑构建一套可重复、可维护、高置信度的自动化验证体系。我经历过不止一次因为路由测试缺失而导致的线上事故。有一次我们在一个守卫里添加了一个新的权限判断自测时一切正常结果上线后部分老用户无法访问历史订单页面。排查后发现是因为守卫中异步获取用户信息的逻辑与某些特定路由的进入时机产生了竞态条件而我们的手动测试完全覆盖不到这种边缘场景。从那以后我坚信路由测试不是可选项而是与组件测试、状态管理测试同等重要的基础设施。那么这套策略适合谁如果你是Vue.js的初学者正在构建第一个包含多页面的应用了解基础的测试方法能帮你建立正确的开发习惯避免后期补测试的巨额成本。如果你是中高级开发者负责维护一个中大型的Vue项目深入的路由测试策略能显著提升代码的健壮性和团队协作的效率尤其是在进行路由重构或权限模型升级时它能给你足够的“安全感”。本质上任何希望自己的应用导航行为可预测、可追溯的开发者都需要掌握这些策略。2. 测试环境搭建与工具选型解析工欲善其事必先利其器。测试Vue Router我们首先需要的是一个贴近真实、但又足够轻量和可控的测试环境。直接使用一个完整的、挂载了真实Router实例的Vue应用进行测试不仅笨重而且难以模拟各种边界情况如导航中止、错误。因此我们的策略核心是隔离与模拟。2.1 核心测试库Vitest Vue Test Utils目前Vue生态的测试首选是Vitest它速度快、与Vite集成度好并且兼容Jest的API。与之配套的是vue/test-utils它提供了挂载组件、模拟交互等能力。对于路由测试我们还需要vue-router本身以及一个专门用于创建测试用路由实例的辅助库。# 项目初始化或安装测试依赖 npm install -D vitest vue/test-utils happy-dom npm install vue-router这里选择happy-dom作为测试环境environment因为它比jsdom更轻量且能更好地模拟浏览器环境这对于需要测试window.location或historyAPI的路由场景很重要。在你的vitest.config.js中需要进行相应配置。2.2 路由测试的“脚手架”创建可复用的测试路由工厂这是第一个关键技巧。我们不应该在每个测试文件中都重新创建一遍完整的主应用路由。相反应该建立一个工厂函数允许我们为每个测试用例动态地、按需地创建路由配置。// tests/unit/router/testRouterFactory.js import { createRouter, createWebHistory } from vue-router; /** * 创建一个用于测试的Router实例 * param {Array} routes - 覆盖或新增的路由配置 * param {String} initialRoute - 初始路由地址 * returns {Router} 配置好的Router实例 */ export function createTestRouter(routes [], initialRoute /) { // 基础路由配置通常是你的应用路由的一个子集或简化版 const baseRoutes [ { path: /, name: Home, component: { template: divHome/div } }, { path: /about, name: About, component: { template: divAbout/div } }, { path: /user/:id, name: User, component: { template: divUser/div }, props: true }, ]; const mergedRoutes [...baseRoutes, ...routes]; const router createRouter({ history: createWebHistory(), routes: mergedRoutes, }); // 在测试中我们通常不希望真的改变浏览器的URL所以可以推送到一个模拟的history栈。 // 更常见的做法是使用 createWebHistory 的 memory 模式但为保持与生产环境一致 // 我们选择在测试setup中通过 router.push 来设置初始状态。 if (initialRoute ! /) { // 注意这是一个异步操作在测试中需要await router.push(initialRoute); } return router; }这个工厂函数的好处是显而易见的隔离性。每个测试用例都可以获得一个全新的、干净的Router实例测试之间不会相互污染。你可以通过传入routes参数来测试特定的路由配置比如一个尚未添加到主路由的新功能页面。注意在单元测试中我们通常使用createMemoryHistory来完全避免与真实浏览器历史记录的交互使测试更纯粹。但在组件集成测试中为了更真实地模拟有时会坚持使用createWebHistory。这里展示工厂模式你可以根据测试类型灵活切换history的实现。2.3 测试工具函数的封装导航与守卫的模拟除了路由实例我们经常需要模拟一些导航行为或守卫的上下文。封装一些工具函数能让测试代码更简洁。// tests/unit/router/testUtils.js /** * 模拟一次导航并返回导航结果 * param {Router} router - 路由实例 * param {string} to - 目标路径或路由对象 * returns {PromiseNavigationResult} 导航结果包含是否成功、错误等信息 */ export async function simulateNavigation(router, to) { try { await router.push(to); return { success: true }; } catch (error) { // 导航被守卫拒绝或出错 return { success: false, error }; } } /** * 创建一个模拟的导航守卫上下文对象 * 用于在测试中直接调用守卫函数并验证其行为 * param {string} to - 目标路由路径 * param {string} from - 来源路由路径 * param {Function} next - 可选的next函数模拟 * returns {Object} 守卫上下文对象 */ export function createGuardContext(to /about, from /, next jest.fn()) { return { to: { path: to, fullPath: to, name: undefined, params: {}, query: {} }, from: { path: from, fullPath: from, name: undefined, params: {}, query: {} }, next, }; }这些工具函数将测试中的通用操作抽象出来让我们能更专注于测试逻辑本身而不是重复的样板代码。3. 核心测试策略一路由配置与基本导航的单元测试这一层测试的目标是验证路由配置本身的正确性以及最基本的导航功能是否按预期工作。它不涉及组件渲染只关注路由对象和Router实例的行为。3.1 测试路由配置Route Config你的router/index.js文件里定义了一堆路由规则。它们真的对吗动态参数/:id能正确匹配吗嵌套路由的children路径拼接对吗这些可以通过直接导入路由配置并进行测试来验证。// tests/unit/router/routeConfig.spec.js import { routes } from /router; import { createRouter, createWebHistory } from vue-router; describe(Route Configuration, () { let router; beforeEach(() { router createRouter({ history: createWebHistory(), routes, }); }); it(应该正确解析根路径到Home组件, () { const route router.resolve(/); expect(route.name).toBe(Home); // 可以进一步检查匹配到的组件或其他元信息 // expect(route.matched[0].components.default).toBe(HomeView); }); it(应该正确解析动态用户路由并提取参数, () { const userId 123; const route router.resolve(/user/${userId}); expect(route.name).toBe(UserDetail); expect(route.params).toEqual({ id: userId }); }); it(嵌套路由的路径应正确拼接, () { // 假设有路由{ path: /settings, children: [ { path: profile, ... } ] } const route router.resolve(/settings/profile); expect(route.matched).toHaveLength(2); // 匹配到父路由和子路由 expect(route.matched[1].path).toBe(/settings/profile); }); it(查询参数query应能被正确解析, () { const route router.resolve(/search?qvuesortdesc); expect(route.path).toBe(/search); expect(route.query).toEqual({ q: vue, sort: desc }); }); });这种测试非常轻量快速它能确保你的路由表这个“地图”本身没有画错。在重构路由结构或添加复杂嵌套时运行这套测试能给你即时反馈。3.2 测试基本导航与Router实例方法接下来我们测试Router实例的API比如router.push,router.replace,router.go等。// tests/unit/router/routerInstance.spec.js import { createTestRouter } from ./testRouterFactory; describe(Router Instance Methods, () { let router; beforeEach(async () { router createTestRouter(); // 确保路由器已安装并处于就绪状态这对于基于History API的导航是必要的。 // 在测试环境中我们可能需要手动启动路由器。 // 一种常见模式是将router安装在一个空的div上。 const div document.createElement(div); div.id app; document.body.appendChild(div); await router.isReady(); }); afterEach(() { const appDiv document.getElementById(app); if (appDiv) { document.body.removeChild(appDiv); } }); it(router.push 应能成功导航到新路由, async () { await router.push(/about); expect(router.currentRoute.value.path).toBe(/about); }); it(router.replace 应替换当前历史记录条目, async () { const initialLength window.history.length; await router.push(/); await router.replace(/about); expect(router.currentRoute.value.path).toBe(/about); // 注意在happy-dom中history.length的行为可能与真实浏览器有差异。 // 这个断言更多是概念性的实际测试中可能更关注路由状态而非history对象。 }); it(router.back 应能回退到上一个路由, async () { await router.push(/); await router.push(/about); await router.back(); expect(router.currentRoute.value.path).toBe(/); }); });这里的关键点是异步处理。router.push返回一个Promise你必须使用await或在then中处理。忘记处理异步是路由测试中最常见的错误之一会导致测试断言在导航完成前就执行从而得到错误结果。实操心得在测试router.back()或router.go()时由于它们依赖于浏览器的历史记录栈在测试环境中行为可能不稳定。一个更可靠的方法是直接测试router.currentRoute.value的变化或者使用createMemoryHistory来获得完全可控的历史记录管理。4. 核心测试策略二导航守卫Navigation Guards的深度测试导航守卫是Vue Router中最强大也最容易出错的部分。全局守卫、路由独享守卫、组件内守卫它们构成了复杂的导航控制流。测试守卫的目标是确保在各种输入路由参数、用户状态下守卫能做出正确的“放行”、“重定向”或“中止”决策。4.1 测试全局守卫全局守卫router.beforeEach等通常包含权限校验、日志记录等关键业务逻辑。测试时我们需要模拟不同的“来”和“去”的路由以及外部状态如用户登录状态。// tests/unit/router/globalGuards.spec.js import { createTestRouter } from ./testRouterFactory; import { createGuardContext } from ./testUtils; import { useAuthStore } from /stores/auth; // 假设使用Pinia进行状态管理 // 模拟Pinia store vi.mock(/stores/auth, () ({ useAuthStore: vi.fn(), })); describe(Global Navigation Guards, () { let router; let mockAuthStore; let originalBeforeEach; beforeEach(() { // 创建模拟的认证Store mockAuthStore { isAuthenticated: false, user: null, checkAuth: vi.fn(), }; useAuthStore.mockReturnValue(mockAuthStore); // 创建一个带有基础路由的测试路由器 router createTestRouter(); // **关键步骤在这里定义并注册你要测试的全局守卫** // 注意我们直接在这里定义守卫逻辑而不是从生产代码导入 // 以确保测试的独立性和可重复性。实际项目中你可能需要导入真实的守卫函数。 const authGuard (to, from, next) { const auth useAuthStore(); if (to.meta.requiresAuth !auth.isAuthenticated) { next({ name: Login, query: { redirect: to.fullPath } }); } else { next(); } }; // 注册守卫 router.beforeEach(authGuard); }); afterEach(() { // 每个测试后清空守卫避免污染 if (originalBeforeEach) { router.beforeEach(originalBeforeEach); } else { // 如果无法获取原始守卫一个简单粗暴的方法是创建新的Router实例 // 但在beforeEach中我们已经用新实例覆盖所以这里问题不大。 } }); it(当访问需要认证的路由且用户未登录时应重定向到登录页, async () { // 1. 定义一个需要认证的测试路由 const protectedRoute { path: /dashboard, name: Dashboard, meta: { requiresAuth: true } }; const testRouter createTestRouter([protectedRoute]); // 重新注册守卫到新的router实例简化示例实际需提取守卫函数 testRouter.beforeEach((to, from, next) { if (to.meta.requiresAuth !mockAuthStore.isAuthenticated) { next({ name: Login, query: { redirect: to.fullPath } }); } else { next(); } }); // 2. 模拟未登录状态 mockAuthStore.isAuthenticated false; // 3. 尝试导航到受保护路由 await testRouter.push(/dashboard); // 4. 断言导航结果被重定向 expect(testRouter.currentRoute.value.name).toBe(Login); expect(testRouter.currentRoute.value.query.redirect).toBe(/dashboard); }); it(当用户已登录时应允许访问需要认证的路由, async () { const protectedRoute { path: /dashboard, name: Dashboard, meta: { requiresAuth: true } }; const testRouter createTestRouter([protectedRoute]); testRouter.beforeEach((to, from, next) { if (to.meta.requiresAuth !mockAuthStore.isAuthenticated) { next({ name: Login }); } else { next(); } }); mockAuthStore.isAuthenticated true; // 模拟已登录 await testRouter.push(/dashboard); expect(testRouter.currentRoute.value.name).toBe(Dashboard); // 应成功进入 }); it(全局守卫应能正确处理异步逻辑, async () { // 模拟一个需要异步检查的守卫 const asyncGuard (to, from, next) { setTimeout(() { next(); // 模拟异步操作后放行 }, 100); }; router.beforeEach(asyncGuard); // 测试异步导航是否能正确完成 const navigationPromise router.push(/about); // 可以使用 jest.advanceTimersByTime 如果用了假定时器 // 这里我们直接等待Promise完成 await navigationPromise; expect(router.currentRoute.value.path).toBe(/about); }); });测试守卫的难点在于模拟外部依赖如Pinia Store、API调用和控制异步流程。上面的例子展示了如何通过vi.mock来模拟一个Pinia Store从而可以自由控制isAuthenticated的状态对守卫逻辑进行全面的分支覆盖。4.2 测试路由独享守卫和组件内守卫路由独享守卫beforeEnter和组件内守卫beforeRouteEnter等的测试思路与全局守卫类似但需要将它们与特定的路由或组件关联起来测试。对于beforeEnter你可以在创建测试路由时直接将其定义在路由配置中然后测试导航到该路由的行为。对于组件内守卫测试方法更偏向于集成测试你需要挂载包含该守卫的组件并触发导航。这通常使用vue/test-utils的mount或shallowMount来完成。// tests/unit/components/UserProfile.spec.js - 测试组件内守卫 import { mount } from vue/test-utils; import { createTestRouter } from ../router/testRouterFactory; import UserProfile from /components/UserProfile.vue; describe(UserProfile Component Guards, () { let router; let wrapper; beforeEach(async () { router createTestRouter([ { path: /profile/:id, name: Profile, component: UserProfile, // 假设组件内部定义了 beforeRouteEnter 守卫 }, ]); // 导航到该路由以激活组件 await router.push(/profile/123); }); it(beforeRouteEnter 守卫应能阻止未授权访问, async () { // 这个测试比较复杂因为 beforeRouteEnter 在组件实例创建前执行 // 且不能访问 this。 // 一种策略是在测试中我们直接模拟触发导航并断言结果被重定向或取消。 // 更直接的方法是将守卫逻辑提取到一个独立的、可测试的函数中然后单独测试该函数。 // 这里展示一种通过组件挂载的间接测试方式假设守卫会修改组件数据或触发重定向。 // 创建一个模拟的“next”回调检查它被调用时的参数 const mockNext vi.fn(); // 我们需要调用组件内定义的守卫函数。这通常需要访问组件的选项。 // 注意这要求守卫函数在组件选项中是可访问的。 if (UserProfile.beforeRouteEnter) { // 创建一个模拟的上下文 const context createGuardContext(/profile/456, /, mockNext); // 调用守卫函数 await UserProfile.beforeRouteEnter.call(null, context.to, context.from, mockNext); // 根据你的守卫逻辑进行断言 // 例如如果未授权next应该被调用并传入一个重定向对象或false // expect(mockNext).toHaveBeenCalledWith(false); // 或 expect(mockNext).toHaveBeenCalledWith({ name: Login }); } }); });重要注意事项直接测试组件内守卫尤其是beforeRouteEnter通常比较棘手因为它们的执行时机和上下文限制。最佳实践是将守卫中的复杂逻辑如权限检查、数据预取提取到独立的工具函数、Composable或Store Action中。然后你可以对这些提取出的纯函数进行简单的单元测试而在组件守卫测试中只需验证在特定条件下这些函数是否被正确调用即可。这遵循了“关注点分离”和“易于测试”的设计原则。5. 核心测试策略三组件与路由的集成测试单元测试确保了路由配置和守卫逻辑的正确性但用户最终交互的是组件。集成测试关注的是当路由发生变化时对应的组件是否正确渲染、是否正确接收了参数、其内部行为是否符合预期。5.1 测试路由视图组件RouterView我们通常有一个App.vue组件里面包含一个router-view /。测试它意味着要验证路由切换是否能正确渲染不同的页面组件。// tests/integration/App.spec.js import { mount } from vue/test-utils; import { createTestRouter } from ../unit/router/testRouterFactory; import App from /App.vue; import HomeView from /views/HomeView.vue; import AboutView from /views/AboutView.vue; // 使用真实组件但可以浅层渲染shallow它们的子组件 vi.mock(/views/HomeView.vue, () ({ default: { template: div>// tests/unit/components/UserDetail.spec.js import { mount } from vue/test-utils; import { createTestRouter } from ../router/testRouterFactory; import UserDetail from /components/UserDetail.vue; describe(UserDetail Component with Route Params, () { let router; let wrapper; const mountComponentWithRoute async (routePath) { router createTestRouter(); // 导航到特定路由 await router.push(routePath); wrapper mount(UserDetail, { global: { plugins: [router], }, }); // 等待组件可能进行的异步操作如根据id获取用户数据 await wrapper.vm.$nextTick(); }; it(应根据路由参数 :id 显示对应的用户信息, async () { const userId 789; // 假设 UserDetail 组件内部使用 useRoute().params.id 来获取ID并显示 await mountComponentWithRoute(/user/${userId}); // 断言组件渲染的内容包含了该ID具体断言取决于组件实现 expect(wrapper.text()).toContain(User ID: ${userId}); }); it(当路由参数变化时组件应能响应并更新, async () { // 先挂载到一个ID await mountComponentWithRoute(/user/111); const initialText wrapper.text(); // 然后通过router改变路由参数 await router.push(/user/222); // 等待Vue响应式更新和组件可能的异步操作 await wrapper.vm.$nextTick(); const updatedText wrapper.text(); expect(updatedText).not.toBe(initialText); expect(updatedText).toContain(User ID: 222); }); it(应能正确处理路由查询参数query, async () { await mountComponentWithRoute(/search?qVuepage2); // 假设组件内部使用 useRoute().query 来获取查询参数 // 断言组件根据 q 和 page 做出了正确的行为如发起搜索请求、高亮页码 // 这里可以检查组件内部状态或发出的HTTP请求如果使用了如axios-mock-adapter expect(wrapper.vm.searchQuery).toBe(Vue); // 假设组件有一个searchQuery数据属性 expect(wrapper.vm.currentPage).toBe(2); }); });这里的关键是模拟路由变化并断言组件的响应。我们通过router.push来改变路由状态然后使用await wrapper.vm.$nextTick()来等待Vue的DOM更新队列。如果组件在updated生命周期或watch中执行了异步操作如API调用可能还需要使用flushPromises或更长的等待时间。实操心得对于严重依赖路由参数的组件考虑将其数据获取逻辑如根据ID获取详情提取到Composable或Pinia Action中。这样你可以单独测试数据获取逻辑而在组件集成测试中只需模拟mock这个Composable或Action验证组件在接收到不同参数时是否调用了正确的函数。这能大幅降低测试的复杂度和耦合度。6. 常见问题、陷阱与排查技巧实录在实际项目中测试Vue Router你会遇到各种“坑”。下面是我总结的一些典型问题及其解决方案。6.1 异步导航导致的测试竞态条件这是最常见的问题。router.push()是异步的它返回一个Promise。如果你在导航完成前就进行断言测试就会失败。症状测试不稳定有时通过有时失败。错误信息可能指向router.currentRoute.value不是期望的值。解决方案始终await导航操作await router.push(‘/some-path’)。在导航后等待Vue更新await wrapper.vm.$nextTick()。使用router.isReady()在挂载依赖于路由的组件前确保初始导航已完成await router.isReady()。对于更复杂的异步链如导航守卫中有API调用考虑使用flushPromises工具函数来确保所有微任务microtasks都执行完毕。// 一个工具函数用于“排空”Promise队列 function flushPromises() { return new Promise(resolve setImmediate(resolve)); } it(应处理异步守卫后的导航, async () { // ... 模拟一个执行异步操作的守卫 const navigationPromise router.push(/target); await flushPromises(); // 确保守卫中的异步操作完成 await navigationPromise; // 确保导航Promise完成 await wrapper.vm.$nextTick(); // 确保组件更新 // 现在进行断言 expect(router.currentRoute.value.path).toBe(/target); });6.2 模拟Mock的过度使用或错误使用为了隔离测试我们需要模拟外部依赖。但过度模拟会导致测试失去意义而错误的模拟则会让测试通过但实际代码失败。症状测试全部通过但应用在真实浏览器中行为异常。解决方案遵循“黑盒测试”原则对于你要测试的单元如一个守卫函数只模拟其外部依赖如HTTP客户端、状态存储不要模拟其内部实现或Vue Router自身的API除非你明确在测试Router的某个边缘行为。使用vi.spyOn进行行为验证与其模拟整个模块不如使用间谍spy来验证某个函数是否被以正确的参数调用。import * as authService from /services/auth; it(守卫应调用认证检查服务, async () { const checkSpy vi.spyOn(authService, checkPermission); await router.push(/admin); expect(checkSpy).toHaveBeenCalledWith(expect.objectContaining({ path: /admin })); });谨慎模拟useRoute/useRouter在测试组件时通常更好的方法是通过global.plugins提供真实的Router实例让组件使用真实的useRoute。如果必须模拟确保模拟的函数返回正确的响应式对象。6.3 测试中路由历史记录的污染在测试中连续进行多次router.push历史记录栈会增长可能影响后续测试的初始状态。症状一个测试的成功依赖于前一个测试留下的路由状态。解决方案为每个测试创建新的Router实例这是最彻底的方法使用前面介绍的createTestRouter工厂函数。在每个测试后重置路由如果不创建新实例可以在afterEach中手动将路由重置到初始状态。afterEach(async () { // 回到根路径并清空历史如果可能 await router.push(/); // 注意在基于WebHistory的路由器中无法直接清空浏览器历史栈。 // 因此创建新实例通常是更安全的选择。 });6.4 组件内守卫beforeRouteEnter的测试困境如前所述beforeRouteEnter在组件实例创建前调用且无法访问this测试起来很别扭。解决方案提取逻辑将beforeRouteEnter中的业务逻辑如数据预取提取到一个独立的函数或Composable中。测试提取出的函数对这个纯函数进行单元测试覆盖各种输入输出。简化组件守卫测试在组件测试中只需验证beforeRouteEnter是否调用了那个提取出的函数。你可以使用vi.spyOn来监视该函数。// 假设提取出的函数叫 fetchUserData import { fetchUserData } from /composables/useUserData; vi.mock(/composables/useUserData); it(beforeRouteEnter 应调用数据预取函数, async () { await router.push(/user/123); expect(fetchUserData).toHaveBeenCalledWith(123); });6.5 路由别名Alias和重定向Redirect的测试这些功能容易在手动测试中被忽略但自动化测试可以轻松覆盖。测试方法直接使用router.resolve()方法检查给定的URL是否被正确解析重定向到目标路由记录。it(别名 /home 应解析到根路径 /, () { const route router.resolve(/home); expect(route.matched[0].path).toBe(/); // 或者检查route.redirectedFrom }); it(路径 /old 应重定向到 /new, () { const route router.resolve(/old); expect(route.path).toBe(/new); });6.6 问题排查速查表当你遇到路由测试失败时可以按以下顺序排查问题现象可能原因排查步骤导航后currentRoute未更新1. 未await router.push2. 导航被守卫阻止但未处理错误3. 测试环境历史记录异常1. 确保所有导航操作都用了await。2. 用try...catch包裹导航打印错误。3. 尝试使用createMemoryHistory。组件未随路由切换更新1. 未等待$nextTick2.router-view的key属性问题3. 组件未正确注册或引入1. 在router.push后加await wrapper.vm.$nextTick()。2. 检查组件是否对路由变化做出响应watch了$route。3. 检查测试中路由配置的component字段是否正确。守卫逻辑未按预期执行1. 守卫注册时机不对2. 模拟mock覆盖了真实守卫3. 守卫内部条件判断有误1. 确认守卫是在router.beforeEach调用前注册的。2. 检查测试中是否有vi.mock意外模拟了路由模块。3. 在守卫内部添加console.log或使用调试器检查执行流和变量值。测试通过但真实环境失败1. 模拟mock过于乐观2. 测试环境与生产环境路由模式不同hash vs history3. 基础路径base配置差异1. 审查mock实现确保其行为与真实依赖一致尤其是错误情况。2. 确保测试和生产使用相同的history模式如createWebHistory。3. 检查createRouter的history配置中是否有不同的base参数。记住好的路由测试应该是确定性的每次运行结果一致、快速的、专注于单一功能点的。从简单的路由配置测试开始逐步深入到复杂的守卫和组件集成测试建立起一个坚实的测试网这样你在重构路由或添加新功能时就能拥有一个可靠的安全网。