做网站建设专业定制,怎么样签约设计网站,广州公司注册名字查询,南京小程序制作公司如果您有疑问#xff0c;请观看视频教程《Vue3实战教程》 测试
为什么需要测试
自动化测试能够预防无意引入的 bug#xff0c;并鼓励开发者将应用分解为可测试、可维护的函数、模块、类和组件。这能够帮助你和你的团队更快速、自信地构建复杂的 Vue 应用。与任何应用一…如果您有疑问请观看视频教程《Vue3实战教程》 测试
为什么需要测试
自动化测试能够预防无意引入的 bug并鼓励开发者将应用分解为可测试、可维护的函数、模块、类和组件。这能够帮助你和你的团队更快速、自信地构建复杂的 Vue 应用。与任何应用一样新的 Vue 应用可能会以多种方式崩溃因此在发布前发现并解决这些问题就变得十分重要。
在本篇指引中我们将介绍一些基本术语并就你的 Vue 3 应用应选择哪些工具提供一些建议。
还有一个特定用于 Vue 的小节介绍了组合式函数的测试详情请参阅测试组合式函数。
何时测试
越早越好我们建议你尽快开始编写测试。拖得越久应用就会有越多的依赖和复杂性想要开始添加测试也就越困难。
测试的类型
当设计你的 Vue 应用的测试策略时你应该利用以下几种测试类型
单元测试检查给定函数、类或组合式函数的输入是否产生预期的输出或副作用。组件测试检查你的组件是否正常挂载和渲染、是否可以与之互动以及表现是否符合预期。这些测试比单元测试导入了更多的代码更复杂需要更多时间来执行。端到端测试检查跨越多个页面的功能并对生产构建的 Vue 应用进行实际的网络请求。这些测试通常涉及到建立一个数据库或其他后端。
每种测试类型在你的应用的测试策略中都发挥着作用保护你免受不同类型的问题的影响。
总览
我们将简要地讨论这些测试是什么以及如何在 Vue 应用中实现它们并提供一些普适性建议。
单元测试
编写单元测试是为了验证小的、独立的代码单元是否按预期工作。一个单元测试通常覆盖一个单个函数、类、组合式函数或模块。单元测试侧重于逻辑上的正确性只关注应用整体功能的一小部分。他们可能会模拟你的应用环境的很大一部分如初始状态、复杂的类、第三方模块和网络请求。
一般来说单元测试将捕获函数的业务逻辑和逻辑正确性的问题。
以这个 increment 函数为例
js
// helpers.js
export function increment(current, max 10) {if (current max) {return current 1}return current
}
因为它很独立可以很容易地调用 increment 函数并断言它是否返回了所期望的内容所以我们将编写一个单元测试。
如果任何一条断言失败了那么问题一定是出在 increment 函数上。
js
// helpers.spec.js
import { increment } from ./helpersdescribe(increment, () {test(increments the current number by 1, () {expect(increment(0, 10)).toBe(1)})test(does not increment the current number over the max, () {expect(increment(10, 10)).toBe(10)})test(has a default max of 10, () {expect(increment(10)).toBe(10)})
})
如前所述单元测试通常适用于独立的业务逻辑、组件、类、模块或函数不涉及 UI 渲染、网络请求或其他环境问题。
这些通常是与 Vue 无关的纯 JavaScript/TypeScript 模块。一般来说在 Vue 应用中为业务逻辑编写单元测试与使用其他框架的应用没有明显区别。
但有两种情况你必须对 Vue 的特定功能进行单元测试
组合式函数组件
组合式函数
有一类 Vue 应用中特有的函数被称为 组合式函数在测试过程中可能需要特殊处理。 你可以跳转到下方查看 测试组合式函数 了解更多细节。
组件的单元测试
一个组件可以通过两种方式测试 白盒单元测试 白盒测试知晓一个组件的实现细节和依赖关系。它们更专注于将组件进行更 独立 的测试。这些测试通常会涉及到模拟一些组件的部分子组件以及设置插件的状态和依赖性例如 Pinia。 黑盒组件测试 黑盒测试不知晓一个组件的实现细节。这些测试尽可能少地模拟以测试组件在整个系统中的集成情况。它们通常会渲染所有子组件因而会被认为更像一种“集成测试”。请查看下方的组件测试建议作进一步了解。
推荐方案 Vitest 因为由 create-vue 创建的官方项目配置是基于 Vite 的所以我们推荐你使用一个可以利用同一套 Vite 配置和转换管道的单元测试框架。Vitest 正是一个针对此目标设计的单元测试框架它由 Vue / Vite 团队成员开发和维护。在 Vite 的项目集成它会非常简单而且速度非常快。
其他选择
Jest 是一个广受欢迎的单元测试框架。不过我们只推荐你在已有一套 Jest 测试配置、且需要迁移到基于 Vite 的项目时使用它因为 Vitest 提供了更无缝的集成和更好的性能。
组件测试
在 Vue 应用中主要用组件来构建用户界面。因此当验证应用的行为时组件是一个很自然的独立单元。从粒度的角度来看组件测试位于单元测试之上可以被认为是集成测试的一种形式。你的 Vue 应用中大部分内容都应该由组件测试来覆盖我们建议每个 Vue 组件都应有自己的组件测试文件。
组件测试应该捕捉组件中的 prop、事件、提供的插槽、样式、CSS class 名、生命周期钩子和其他相关的问题。
组件测试不应该模拟子组件而应该像用户一样通过与组件互动来测试组件和其子组件之间的交互。例如组件测试应该像用户那样点击一个元素而不是编程式地与组件进行交互。
组件测试主要需要关心组件的公开接口而不是内部实现细节。对于大部分的组件来说公开接口包括触发的事件、prop 和插槽。当进行测试时请记住测试这个组件做了什么而不是测试它是怎么做到的。 推荐的做法 对于 视图 的测试根据输入 prop 和插槽断言渲染输出是否正确。对于 交互 的测试断言渲染的更新是否正确或触发的事件是否正确地响应了用户输入事件。在下面的例子中我们展示了一个步进器Stepper组件它拥有一个标记为 increment 的可点击的 DOM 元素。我们还传入了一个名为 max 的 prop 防止步进器增长超过 2因此如果我们点击了按钮 3 次视图将仍然显示 2。 我们不了解这个步进器的实现细节只知道“输入”是这个 max prop“输出”是这个组件状态所呈现出的视图。
Vue Test Utils
Cypress
Testing Library
js
const valueSelector [data-testidstepper-value]
const buttonSelector [data-testidincrement]const wrapper mount(Stepper, {props: {max: 1}
})expect(wrapper.find(valueSelector).text()).toContain(0)await wrapper.find(buttonSelector).trigger(click)expect(wrapper.find(valueSelector).text()).toContain(1)
应避免的做法 不要去断言一个组件实例的私有状态或测试一个组件的私有方法。测试实现细节会使测试代码太脆弱因为当实现发生变化时它们更有可能失败并需要更新重写。 组件的最终工作是渲染正确的 DOM 输出所以专注于 DOM 输出的测试提供了足够的正确性保证如果你不需要更多其他方面测试的话同时更加健壮、需要的改动更少。 不要完全依赖快照测试。断言 HTML 字符串并不能完全说明正确性。应当编写有意图的测试。 如果一个方法需要测试把它提取到一个独立的实用函数中并为它写一个专门的单元测试。如果它不能被直截了当地抽离出来那么对它的调用应该作为交互测试的一部分。
推荐方案 Vitest 对于组件和组合式函数都采用无头渲染的方式 (例如 VueUse 中的 useFavicon 函数)。组件和 DOM 都可以通过 vue/test-utils 来测试。 Cypress 组件测试 会预期其准确地渲染样式或者触发原生 DOM 事件。它可以搭配 testing-library/cypress 这个库一同进行测试。
Vitest 和基于浏览器的运行器之间的主要区别是速度和执行上下文。简而言之基于浏览器的运行器如 Cypress可以捕捉到基于 Node 的运行器如 Vitest所不能捕捉的问题比如样式问题、原生 DOM 事件、Cookies、本地存储和网络故障但基于浏览器的运行器比 Vitest 慢几个数量级因为它们要执行打开浏览器编译样式表以及其他步骤。Cypress 是一个基于浏览器的运行器支持组件测试。请阅读 Vitest 文档的“比较”这一章 了解 Vitest 和 Cypress 最新的比较信息。
组件挂载库
组件测试通常涉及到单独挂载被测试的组件触发模拟的用户输入事件并对渲染的 DOM 输出进行断言。有一些专门的工具库可以使这些任务变得更简单。 vue/test-utils 是官方的底层组件测试库用来提供给用户访问 Vue 特有的 API。testing-library/vue 也是基于此库构建的。 testing-library/vue 是一个专注于测试组件而不依赖于实现细节的 Vue 测试库。它的指导原则是测试越是类似于软件的使用方式它们就能提供越多的信心。
我们推荐在应用中使用 vue/test-utils 测试组件。testing-library/vue 在测试带有 Suspense 的异步组件时存在问题在使用时需要谨慎。
其他选择 Nightwatch 是一个端到端测试运行器支持 Vue 的组件测试。(Nightwatch v2 版本的 示例项目) WebdriverIO 用于跨浏览器组件测试该测试依赖于基于标准自动化的原生用户交互。它也可以与测试库一起使用。
端到端E2E测试
虽然单元测试为所写的代码提供了一定程度的验证但单元测试和组件测试在部署到生产时对应用整体覆盖的能力有限。因此端到端测试针对的可以说是应用最重要的方面当用户实际使用你的应用时发生了什么。
端到端测试的重点是多页面的应用表现针对你的应用在生产环境下进行网络请求。他们通常需要建立一个数据库或其他形式的后端甚至可能针对一个预备上线的环境运行。
端到端测试通常会捕捉到路由、状态管理库、顶级组件常见为 App 或 Layout、公共资源或任何请求处理方面的问题。如上所述它们可以捕捉到单元测试或组件测试无法捕捉的关键问题。
端到端测试不导入任何 Vue 应用的代码而是完全依靠在真实浏览器中浏览整个页面来测试你的应用。
端到端测试验证了你的应用中的许多层。可以在你的本地构建的应用中甚至是一个预上线的环境中运行。针对预上线环境的测试不仅包括你的前端代码和静态服务器还包括所有相关的后端服务和基础设施。 你的测试越是类似于你的软件的使用方式它们就越能值得你信赖。- Kent C. Dodds - Testing Library 的作者 通过测试用户操作如何影响你的应用端到端测试通常是提高应用能否正常运行的置信度的关键。
选择一个端到端测试解决方案
虽然因为不可靠且拖慢了开发过程市面上对 Web 上的端到端测试的评价并不好但现代端到端工具已经在创建更可靠、更有用和交互性更好的测试方面取得了很大进步。在选择端到端测试框架时以下小节会为你给应用选择测试框架时需要注意的事项提供一些指导。
跨浏览器测试
端到端测试的一个主要优点是你可以了解你的应用在多个不同浏览器上运行的情况。尽管理想情况应该是 100% 的跨浏览器覆盖率但很重要的一点是跨浏览器测试对团队资源的回报是递减的因为需要额外的时间和机器来持续运行它们。因此在选择应用所需的跨浏览器测试的数量时注意权衡是很有必要的。
更快的反馈
端到端测试和相应开发过程的主要问题之一是运行整个套件需要很长的时间。通常情况下这只在持续集成和部署CI/CD管道中进行。现代的端到端测试框架通过增加并行化等功能来帮助解决这个问题这使得 CI/CD 管道的运行速度比以前快了几倍。此外在本地开发时能够有选择地为你正在工作的页面运行单个测试同时还提供测试的热重载大大提高了开发者的工作流程和生产力。
第一优先级的调试体验
传统上开发者依靠扫描终端窗口中的日志来帮助确定测试中出现的问题而现代端到端测试框架允许开发者利用他们已经熟悉的工具例如浏览器开发工具。
无头模式下的可见性
当端到端测试在 CI/CD 管道中运行时它们通常在无头浏览器即不带界面的浏览器中运行。因此当错误发生时现代端到端测试框架的一个关键特性是能够在不同的测试阶段查看应用的快照、视频从而深入了解错误的原因。而在很早以前要手动维护这些集成是非常繁琐的。
推荐方案 Playwright 是一个非常好的端到端测试解决方案支持 Chromium、WebKit 和 Firefox。在 Windows、Linux 和 macOS 上进行本地或 CI 测试、无头测试或使用适用于 Android 和 Mobile Safari 的 Google Chrome 的原生移动端模拟测试。它拥有信息丰富的用户界面、出色的调试能力、内置断言、并行处理功能以及追踪功能旨在消除不稳定的测试。它还提供对组件测试的支持但目前处于实验阶段。Playwright 由微软开源并维护。 Cypress 具有信息丰富的图形界面、出色的调试性、内置断言、存根、抗剥落性、并行化和快照等诸多特性。而且如上所述它还提供对 组件测试 的支持。它支持基于 Chromium 的浏览器、Firefox 和 Electron。但 WebKit 被标记为实验性支持。Cypress 采用 MIT 许可但并行化等部分功能需要订阅 Cypress Cloud。 测试赞助商
Lambdatest 是一个云平台用于在所有主流浏览器和真实设备上运行 E2E、可访问性和可视化回归测试并提供人工智能辅助测试生成
其他选项 Nightwatch 是一个基于 Selenium WebDriver 的端到端测试解决方案。它的浏览器品类支持范围是最广的包括原生移动测试。基于 Selenium 的解决方案将比 Playwright 或 Cypress 慢。 WebdriverIO 是一个基于 WebDriver 协议的网络和移动测试的自动化测试框架。
用例指南
添加 Vitest 到项目中
在一个基于 Vite 的 Vue 项目中运行如下命令
sh npm install -D vitest happy-dom testing-library/vue
接着更新你的 Vite 配置添加上 test 选项
js
// vite.config.js
import { defineConfig } from viteexport default defineConfig({// ...test: {// 启用类似 jest 的全局测试 APIglobals: true,// 使用 happy-dom 模拟 DOM// 这需要你安装 happy-dom 作为对等依赖peer dependencyenvironment: happy-dom}
})
TIP
如果使用 TypeScript请将 vitest/globals 添加到 tsconfig.json 的 types 字段当中。
json
// tsconfig.json{compilerOptions: {types: [vitest/globals]}
}
接着在你的项目中创建名字以 *.test.js 结尾的文件。你可以把所有的测试文件放在项目根目录下的 test 目录中或者放在源文件旁边的 test 目录中。Vitest 会使用命名规则自动搜索它们。
js
// MyComponent.test.js
import { render } from testing-library/vue
import MyComponent from ./MyComponent.vuetest(it should work, () {const { getByText } render(MyComponent, {props: {/* ... */}})// 断言输出getByText(...)
})
最后在 package.json 之中添加测试命令然后运行它
json
{// ...scripts: {test: vitest}
}
sh npm test
测试组合式函数 这一小节假设你已经读过了组合式函数这一章。 当涉及到测试组合式函数时我们可以根据是否依赖宿主组件实例把它们分为两类。
当一个组合式函数使用以下 API 时它依赖于一个宿主组件实例
生命周期钩子供给/注入
如果一个组合式程序只使用响应式 API那么它可以通过直接调用并断言其返回的状态或方法来进行测试。
js
// counter.js
import { ref } from vueexport function useCounter() {const count ref(0)const increment () count.valuereturn {count,increment}
}
js
// counter.test.js
import { useCounter } from ./counter.jstest(useCounter, () {const { count, increment } useCounter()expect(count.value).toBe(0)increment()expect(count.value).toBe(1)
})
一个依赖生命周期钩子或供给/注入的组合式函数需要被包装在一个宿主组件中才可以测试。我们可以创建下面这样的帮手函数
js
// test-utils.js
import { createApp } from vueexport function withSetup(composable) {let resultconst app createApp({setup() {result composable()// 忽略模板警告return () {}}})app.mount(document.createElement(div))// 返回结果与应用实例// 用来测试供给和组件卸载return [result, app]
}
js
import { withSetup } from ./test-utils
import { useFoo } from ./footest(useFoo, () {const [result, app] withSetup(() useFoo(123))// 为注入的测试模拟一方供给app.provide(...)// 执行断言expect(result.foo.value).toBe(1)// 如果需要的话可以这样触发app.unmount()
})
对于更复杂的组合式函数通过使用组件测试编写针对这个包装器组件的测试这会容易很多。
