内容简介:原文:https://medium.com/js-dojo/unit-testing-vue-router-1d091241312由于路由通常会把多个组件牵扯到一起操作,所以一般对其的测试都在 端到端/集成 阶段进行,处于测试金字塔的上层。不过,做一些路由的单元测试还是大有益处的。
原文:https://medium.com/js-dojo/unit-testing-vue-router-1d091241312
由于路由通常会把多个组件牵扯到一起操作,所以一般对其的测试都在 端到端/集成 阶段进行,处于测试金字塔的上层。不过,做一些路由的单元测试还是大有益处的。
对于与路由交互的组件,有两种测试方式:
-
使用一个真正的 router 实例
-
mock 掉
$route
和$router
全局对象
因为大多数 Vue 应用用的都是官方的 Vue Router,所以本文会谈谈这个。
创建组件
我们会弄一个简单的 <App>
,包含一个 /nested-child
路由。访问 /nested-child
则渲染一个 <NestedRoute>
组件。创建 App.vue
文件,并定义如下的最小化组件:
<template> <div id="app"> <router-view /> </div> </template> <script> export default { name: 'app' } </script>
<NestedRoute>
同样迷你:
<template> <div>Nested Route</div> </template> <script> export default { name: "NestedRoute" } </script>
现在定义一个路由:
import NestedRoute from "@/components/NestedRoute.vue" export default [ { path: "/nested-route", component: NestedRoute } ]
在真实的应用中,一般会创建一个 router.js
文件并导入定义好的路由,写出来一般是这样的:
import Vue from "vue" import VueRouter from "vue-router" import routes from "./routes.js" Vue.use(VueRouter) export default new VueRouter({ routes })
为避免调用 Vue.use(...)
污染测试的全局命名空间,我们将会在测试中创建基础的路由;这让我们能在单元测试期间更细粒度的控制应用的状态。
编写测试
先看点代码再说吧。我们来测试 App.vue
,所以相应的增加一个 App.spec.js
:
import { shallowMount, mount, createLocalVue } from "@vue/test-utils" import App from "@/App.vue" import VueRouter from "vue-router" import NestedRoute from "@/components/NestedRoute.vue" import routes from "@/routes.js" const localVue = createLocalVue() localVue.use(VueRouter) describe("App", () => { it("renders a child component via routing", () => { const router = new VueRouter({ routes }) const wrapper = mount(App, { localVue, router }) router.push("/nested-route") expect(wrapper.find(NestedRoute).exists()).toBe(true) }) })
照例,一开始先把各种模块引入我们的测试;尤其是引入了应用中所需的真实路由。这在某种程度上很理想 -- 若真实路由一旦挂了,单元测试就失败,这样我们就能在部署应用之前修复这类问题。
可以在 <App>
测试中使用一个相同的 localVue
,并将其声明在第一个 describe
块之外。而由于要为不同的路由做不同的测试,所以把 router
定义在 it
块里。
另一个要注意的是这里用了 mount
而非 shallowMount
。如果用了 shallowMount
,则 <router-link>
就会被忽略,不管当前路由是什么,渲染的其实都是一个无用的替身组件。
为使用了 mount 的大型渲染树做些变通
使用 mount
在某些情况下很好,但有时却是不理想的。比如,当渲染整个 <App>
组件时,正赶上渲染树很大,包含了许多组件,一层层的组件又有自己的子组件。这么些个子组件都要触发各种生命周期钩子、发起 API 请求什么的。
如果你在用 Jest,其强大的 mock 系统为此提供了一个优雅的解决方法。可以简单的 mock 掉子组件,在本例中也就是 <NestedRoute>
。使用了下面的写法后,以上测试也将能通过:
jest.mock("@/components/NestedRoute.vue", () => ({ name: "NestedRoute", render: h => h("div") }))
使用 Mock Router
有时真实路由也不是必要的。现在升级一下 <NestedRoute>
,让其根据当前 URL 的查询字符串显示一个用户名。这次我们用 TDD 实现这个特性。以下是一个基础测试,简单的渲染了组件并写了一句断言:
import { shallowMount } from "@vue/test-utils" import NestedRoute from "@/components/NestedRoute.vue" import routes from "@/routes.js" describe("NestedRoute", () => { it("renders a username from query string", () => { const username = "alice" const wrapper = shallowMount(NestedRoute) expect(wrapper.find(".username").text()).toBe(username) }) })
然而我们并没有 <div class="username">
,所以一运行测试就会报错:
tests/unit/NestedRoute.spec.js NestedRoute ✕ renders a username from query string (25ms) ● NestedRoute › renders a username from query string [vue-test-utils]: find did not return .username, cannot call text() on empty Wrapper
来更新一下 <NestedRoute>
:
<template> <div> Nested Route <div class="username"> {{ $route.params.username }} </div> </div> </template>
现在报错变为了:
tests/unit/NestedRoute.spec.js NestedRoute ✕ renders a username from query string (17ms) ● NestedRoute › renders a username from query string TypeError: Cannot read property 'params' of undefined
这是因为 $route
并不存在。 我们当然可以用一个真正的路由,但在这样的情况下只用一个 mocks
加载选项会更容易些:
it("renders a username from query string", () => { const username = "alice" const wrapper = shallowMount(NestedRoute, { mocks: { $route: { params: { username } } } }) expect(wrapper.find(".username").text()).toBe(username) })
这样测试就能通过了。在本例中,我们没有做任何的导航或是和路由的实现相关的任何其他东西,所以 mocks
就挺好。我们并不真的关心 username
是从查询字符串中怎么来的,只要它出现就好。
测试路由钩子的策略
Vue Router 提供了多种类型的路由钩子, 称为 “navigation guards”。举两个例子如:
-
全局 guards (
router.beforeEach
)。在 router 实例上声明 -
组件内 guards,比如
beforeRouteEnter
。在组件中声明
要确保这些运作正常,一般是集成测试的工作,因为需要一个使用者从一个理由导航到另一个。但也可以用单元测试检验导航 guards 中调用的函数是否正常工作,并更快的获得潜在错误的反馈。这里列出一些如何从导航 guards 中解耦逻辑的策略,以及为此编写的单元测试。
全局 guards
比方说当路由中包含 shouldBustCache
元数据的情况下,有那么一个 bustCache
函数就应该被调用。路由可能长这样:
//routes.js import NestedRoute from "@/components/NestedRoute.vue" export default [ { path: "/nested-route", component: NestedRoute, meta: { shouldBustCache: true } } ]
之所以使用 shouldBustCache
元数据,是为了让缓存无效,从而确保用户不会取得旧数据。一种可能的实现如下:
//router.js import Vue from "vue" import VueRouter from "vue-router" import routes from "./routes.js" import { bustCache } from "./bust-cache.js" Vue.use(VueRouter) const router = new VueRouter({ routes }) router.beforeEach((to, from, next) => { if (to.matched.some(record => record.meta.shouldBustCache)) { bustCache() } next() }) export default router
在单元测试中,你可能想导入 router 实例,并试图通过 router.beforeHooks[0]()
的写法调用 beforeEach
;但这将抛出一个关于 next
的错误 -- 因为没法传入正确的参数。针对这个问题,一种策略是在将 beforeEach
导航钩子耦合到路由中之前,解耦并单独导出它。做法是这样的:
//router.js export function beforeEach((to, from, next) { if (to.matched.some(record => record.meta.shouldBustCache)) { bustCache() } next() } router.beforeEach((to, from, next) => beforeEach(to, from, next)) export default router
再写测试就容易了,虽然写起来有点长:
import { beforeEach } from "@/router.js" import mockModule from "@/bust-cache.js" jest.mock("@/bust-cache.js", () => ({ bustCache: jest.fn() })) describe("beforeEach", () => { afterEach(() => { mockModule.bustCache.mockClear() }) it("busts the cache when going to /user", () => { const to = { matched: [{ meta: { shouldBustCache: true } }] } const next = jest.fn() beforeEach(to, undefined, next) expect(mockModule.bustCache).toHaveBeenCalled() expect(next).toHaveBeenCalled() }) it("busts the cache when going to /user", () => { const to = { matched: [{ meta: { shouldBustCache: false } }] } const next = jest.fn() beforeEach(to, undefined, next) expect(mockModule.bustCache).not.toHaveBeenCalled() expect(next).toHaveBeenCalled() }) })
最主要的有趣之处在于,我们借助 jest.mock
,mock 掉了整个模块,并用 afterEach
钩子将其复原。通过将 beforeEach
导出为一个已结耦的、普通的 Javascript 函数,从而让其在测试中不成问题。
为了确定 hook 真的调用了 bustCache
并且显示了最新的数据,可以使用一个诸如 Cypress.io 的端到端测试工具,它也在应用脚手架 vue-cli
的选项中提供了。
组件 guards
一旦将组件 guards 视为已结耦的、普通的 Javascript 函数,则它们也是易于测试的。假设我们为 <NestedRoute>
添加了一个 beforeRouteLeave
hook:
//NestedRoute.vue <script> import { bustCache } from "@/bust-cache.js" export default { name: "NestedRoute", beforeRouteLeave(to, from, next) { bustCache() next() } } </script>
对在全局 guard 中的方法照猫画虎就可以测试它了:
// ... import NestedRoute from "@/compoents/NestedRoute.vue" import mockModule from "@/bust-cache.js" jest.mock("@/bust-cache.js", () => ({ bustCache: jest.fn() })) it("calls bustCache and next when leaving the route", () => { const next = jest.fn() NestedRoute.beforeRouteLeave(undefined, undefined, next) expect(mockModule.bustCache).toHaveBeenCalled() expect(next).toHaveBeenCalled() })
这样的单元测试行之有效,可以在开发过程中立即得到反馈;但由于路由和导航 hooks 常与各种组件互相影响以达到某些效果,也应该做一些集成测试以确保所有事情如预期般工作。
总结
本文讲述了:
-
测试由 Vue Router 条件渲染的组件
-
用
jest.mock
和localVue
去 mock Vue 组件 -
从 router 中解耦全局导航 guard 并对其独立测试
-
用
jest.mock
来 mock 一个模块
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 使用 Gomock 进行单元测试
- 使用JUnit进行单元测试
- 使用Jest进行React单元测试
- Jest & enzyme 进行react单元测试
- 如何实现插入排序以及进行单元格测试
- 如何对 Jenkins 共享库进行单元测试
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
计算机程序设计艺术:第4卷 第4册(双语版)
Donald E.Knuth / 苏运霖 / 机械工业出版社 / 2007-4 / 42.00元
关于算法分析的这多卷论著已经长期被公认为经典计算机科学的定义性描述。迄今已出版的完整的三卷组成了程序设计理论和实践的惟一的珍贵源泉,无数读者都赞扬Knuth的著作对个人的深远影响。科学家们为他的分析的美丽和优雅所惊叹,而从事实践的程序员们已经成功地应用他的“菜谱式”的解到日常问题上,所有人都由于Knuth在书中所表现出的博学、清晰、精确和高度幽默而对他无比敬仰。 为开始后续各卷的写作并更......一起来看看 《计算机程序设计艺术:第4卷 第4册(双语版)》 这本书的介绍吧!
HTML 压缩/解压工具
在线压缩/解压 HTML 代码
HTML 编码/解码
HTML 编码/解码