Vue Router

由于路由通常会把多个组件牵扯到一起操作，所以一般对其的测试都会等到 端到端/集成 测试阶段进行，处于 测试金字塔Vue Router - 图1 的上层。不过，对你的路由做一些单元测试还是大有裨益的。

正如先前章节所讨论的，对于与路由交互的组件，有两种测试方式：

  1. 使用一个真正的 router 实例
  2. mock 掉 $route 和 $router 全局对象

因为大多数 Vue 应用所使用的都是官方的 Vue Router，所以本文会聚焦于这个插件。

在本页中所描述的测试源码可以在 这里Vue Router - 图2 and 这里Vue Router - 图3 找到。

创建组件

我们会设置一个简单的 <App>，包含一个 /nested-child 路由。访问 /nested-child 则渲染一个 <NestedRoute> 子组件。创建 App.vue 文件，并定义如下的最小化组件：

  1. <template>
  2.   <div id="app">
  3.     <router-view />
  4.   </div>
  5. </template>
  7. <script>
  9. export default {
  10.   name: 'app'
  11. }
  12. </script>

<NestedRoute> 同样是最小化的：

  1. <template>
  2.   <div>Nested Route</div>
  3. </template>
  5. <script>
  6. export default {
  7.   name: "NestedRoute"
  8. }
  9. </script>

创建 Router 和 Routes

现在我们需要一些路由用以测试。让我们从以下路由开始：

  1. import NestedRoute from "@/components/NestedRoute.vue"
  3. export default [
  4.   { path: "/nested-route", component: NestedRoute }
  5. ]

在真实的应用中，你一般会创建一个 router.js 文件并导入定义好的路由，并且写出类似这样的代码：

  1. import Vue from "vue"
  2. import VueRouter from "vue-router"
  3. import routes from "./routes.js"
  5. Vue.use(VueRouter)
  7. export default new VueRouter({ routes })

为避免调用 Vue.use(...) 污染测试的全局命名空间，我们将会在测试中创建基础的路由。这让我们能在单元测试期间更细粒度的控制应用的状态。

编写测试

先看点代码再说吧。我们来测试 App.vue，所以相应的添加一个 App.spec.js：

  1. import { shallowMount, mount, createLocalVue } from "@vue/test-utils"
  2. import App from "@/App.vue"
  3. import VueRouter from "vue-router"
  4. import NestedRoute from "@/components/NestedRoute.vue"
  5. import routes from "@/routes.js"
  7. const localVue = createLocalVue()
  8. localVue.use(VueRouter)
  10. describe("App", () => {
  11.   it("renders a child component via routing", async () => {
  12.     const router = new VueRouter({ routes })
  13.     const wrapper = mount(App, { 
  14.       localVue,
  15.       router
  16.     })
  18.     router.push("/nested-route")
  19.     await wrapper.vm.$nextTick()
  21.     expect(wrapper.find(NestedRoute).exists()).toBe(true)
  22.   })
  23. })
  • 请注意测试中标记了 await 并调用了 nextTick。查看 这里 了解其背后原因的更多细节。

照例，一开始先把各种模块引入我们的测试；尤其是引入了应用中所需的真实路由。这在某种程度上很理想 — 若真实路由一旦失败，单元测试随之失败，这样我们就能在部署应用之前修复这类问题。

可以在 <App> 测试中共用一个 localVue，故将其声明在第一个 describe 块之外。而由于要为不同的路由做不同的测试，所以把 router 定义在了 it 块里。

另一个值得注意的有别于其他指南的点是，本例中用了 mount 而非 shallowMount。如果用了 shallowMount，则 <router-link> 就会被忽略，不管当前路由是什么，渲染的其实都是一个无用的 stub 组件。

为使用了 mount 的大型渲染树做些变通

使用 mount 在某些情况下很好，但有时却是不理想的。比如，当渲染整个 <App> 组件时，正赶上渲染树很大，包含了许多组件，一层层的组件又有自己的子组件。这么些个子组件都要触发各种生命周期钩子、发起 API 请求什么的。

如果你在用 Jest，其强大的 mocking 系统为此提供了一个优雅的解决方法。可以简单的 mock 掉子组件，在本例中也就是 <NestedRoute>。使用了下面的写法后，以上测试也将能通过：

  1. jest.mock("@/components/NestedRoute.vue", () => ({
  2.   name: "NestedRoute",
  3.   render: h => h("div")
  4. }))

使用一个 Mock Router

有时真实路由也不是必要的。现在更新一下 <NestedRoute>，让其根据当前 URL 的查询字符串显示一个用户名。这次我们用 TDD 实现这个特性。以下是一个基础测试，简单的渲染了组件并写了一句断言：

  1. import { shallowMount } from "@vue/test-utils"
  2. import NestedRoute from "@/components/NestedRoute.vue"
  3. import routes from "@/routes.js"
  5. describe("NestedRoute", () => {
  6.   it("renders a username from query string", () => {
  7.     const username = "alice"
  8.     const wrapper = shallowMount(NestedRoute)
  10.     expect(wrapper.find(".username").text()).toBe(username)
  11.   })
  12. })

然而我们（译注：在前面提及过的最小化 <NestedRoute> 的中）尚没有 <div class="username"> ，所以一运行测试就会看到：

  1. FAIL  tests/unit/NestedRoute.spec.js
  2.   NestedRoute
  3.     ✕ renders a username from query string (25ms)
  5.   ● NestedRoute › renders a username from query string
  7.     [vue-test-utils]: find did not return .username, cannot call text() on empty Wrapper

更新一下 <NestedRoute>：

  1. <template>
  2.   <div>
  3.     Nested Route
  4.     <div class="username">
  5.       {{ $route.params.username }}
  6.     </div>
  7.   </div>
  8. </template>

现在报错变为了：

  1. FAIL  tests/unit/NestedRoute.spec.js
  2.   NestedRoute
  3.     ✕ renders a username from query string (17ms)
  5.   ● NestedRoute › renders a username from query string
  7.     TypeError: Cannot read property 'params' of undefined

这是因为 $route 并不存在。 我们当然可以用一个真正的路由，但在这样的情况下只用一个 mocks 加载选项会更容易些：

  1. it("renders a username from query string", () => {
  2.   const username = "alice"
  3.   const wrapper = shallowMount(NestedRoute, {
  4.     mocks: {
  5.       $route: {
  6.         params: { username }
  7.       }
  8.     }
  9.   })
  11.   expect(wrapper.find(".username").text()).toBe(username)
  12. })

这样测试就能通过了。在本例中，我们没有做任何的导航或是和路由的实现相关的任何其他东西，所以 mocks 就挺好。我们并不真的关心 username 是从查询字符串中怎么来的，只要它出现就好。

不同于由 Vue Router 负责的客户端路由，通常服务器端也会提供路由功能。在这种情况下，使用 mocks 在一个测试中去设置查询字符串，是替代使用一个真正 Vue Router 实例的一种良好手段。

测试路由钩子的策略

Vue Router 提供了多种类型的路由钩子, 称为 “navigation guards”Vue Router - 图4。举两个例子如：

  1. 全局 guards (router.beforeEach)。在 router 实例上声明。
  2. 组件内 guards，比如 beforeRouteEnter。在组件中声明。

要确保这些运作正常，一般是集成测试的工作，因为需要一个使用者从一个路由导航到另一个。不过，你也可以用单元测试检验导航 guards 中调用的函数是否正常工作，并更快的获得潜在 bugs 的反馈。这里列出一些如何从导航 guards 中解耦逻辑的策略，以及为此编写的单元测试。

全局 guards

假设当路由中包含 shouldBustCache 元数据的情况下，有那么一个 bustCache 函数就应该被调用。路由可能长这样：

  1. import NestedRoute from "@/components/NestedRoute.vue"
  3. export default [
  4.   {
  5.     path: "/nested-route",
  6.     component: NestedRoute,
  7.     meta: {
  8.       shouldBustCache: true
  9.     }
  10.   }
  11. ]

之所以使用 shouldBustCache 元数据，或许是为了让缓存无效，从而确保用户不会取得旧数据。一种可能的实现如下（译注：在这里和之后的例子中不需要关心 bust-cache.js 的实际内容，知道其暴露了 bustCache 方法即可）：

  1. import Vue from "vue"
  2. import VueRouter from "vue-router"
  3. import routes from "./routes.js"
  4. import { bustCache } from "./bust-cache.js"
  6. Vue.use(VueRouter)
  8. const router = new VueRouter({ routes })
  10. router.beforeEach((to, from, next) => {
  11.   if (to.matched.some(record => record.meta.shouldBustCache)) {
  12.     bustCache()
  13.   }
  14.   next()
  15. })
  17. export default router

在你的单元测试中，你 可能 想导入 router 实例，并试图通过 router.beforeHooks[0]() 的写法调用 beforeEach；但这将抛出一个关于 next 的错误 — 因为没法传入正确的参数。针对这个问题，一种策略是在将 beforeEach 导航钩子耦合到路由中之前，解耦并单独导出它。做法是这样的：

  1. // router.js
  3. export function beforeEach(to, from, next) {
  4.   if (to.matched.some(record => record.meta.shouldBustCache)) {
  5.     bustCache()
  6.   }
  7.   next()
  8. }
  10. router.beforeEach((to, from, next) => beforeEach(to, from, next))
  12. export default router

再写测试就容易了，虽然写起来有点长：

  1. import { beforeEach } from "@/router.js"
  2. import mockModule from "@/bust-cache.js"
  4. jest.mock("@/bust-cache.js", () => ({ bustCache: jest.fn() }))
  6. describe("beforeEach", () => {
  7.   afterEach(() => {
  8.     mockModule.bustCache.mockClear()
  9.   })
  11.   it("busts the cache when going to /user", () => {
  12.     const to = {
  13.       matched: [{ meta: { shouldBustCache: true } }]
  14.     }
  15.     const next = jest.fn()
  17.     beforeEach(to, undefined, next)
  19.     expect(mockModule.bustCache).toHaveBeenCalled()
  20.     expect(next).toHaveBeenCalled()
  21.   })
  23.   it("does not bust the cache when going to /user", () => {
  24.     const to = {
  25.       matched: [{ meta: { shouldBustCache: false } }]
  26.     }
  27.     const next = jest.fn()
  29.     beforeEach(to, undefined, next)
  31.     expect(mockModule.bustCache).not.toHaveBeenCalled()
  32.     expect(next).toHaveBeenCalled()
  33.   })
  34. })

最主要的有趣之处在于，我们借助 jest.mock，mock 掉了整个模块，并用 afterEach 钩子将其复原（译注：不要混淆这里 Jest 的 afterEach 和导入的 router 的 beforeEach）。通过将 beforeEach 导出为一个已解耦的、普通的 Javascript 函数，从而让其在测试过程中不成问题。

为了确定 hook 真的调用了 bustCache 并且显示了最新的数据，可以使用一个诸如 Cypress.ioVue Router - 图5 的端到端测试工具，它也在应用脚手架 vue-cli 的选项中提供了，可以被使用。

组件 guards

一旦将组件 guards 视为已解耦的、普通的 Javascript 函数，则它们也是易于测试的。假设我们为 <NestedRoute> 添加了一个 beforeRouteLeave hook：

  1. <script>
  2. import { bustCache } from "@/bust-cache.js"
  3. export default {
  4.   name: "NestedRoute",
  6.   beforeRouteLeave(to, from, next) {
  7.     bustCache()
  8.     next()
  9.   }
  10. }
  11. </script>

对在全局 guards 中的方法照猫画虎就可以测试它了：

  1. // ...
  2. import NestedRoute from "@/components/NestedRoute.vue"
  3. import mockModule from "@/bust-cache.js"
  5. jest.mock("@/bust-cache.js", () => ({ bustCache: jest.fn() }))
  7. it("calls bustCache and next when leaving the route", async () => {
  8.   const wrapper = shallowMount(NestedRoute);
  9.   const next = jest.fn()
  10.   NestedRoute.beforeRouteLeave.call(wrapper.vm, undefined, undefined, next)
  11.   await wrapper.vm.$nextTick()
  14.   expect(mockModule.bustCache).toHaveBeenCalled()
  15.   expect(next).toHaveBeenCalled()
  16. })

这种形式的单元测试行之有效，可以在开发过程中立即得到反馈；但由于路由和导航 hooks 常与各种组件互相影响以达到某些效果，也应该做一些集成测试以确保所有事情如预期般工作。

总结

本文覆盖了：

  • 测试由 Vue Router 条件渲染的组件
  • 用 jest.mock 和 localVue 去 mock Vue 组件
  • 从 router 中解耦全局导航 guard 并对其独立测试
  • 用 jest.mock 来 mock 一个模块

本页中描述的测试源码可以在 这里Vue Router - 图6 and 这里Vue Router - 图7 找到。