可视化测试
没有测试的 Storybook 教程是不完整的。测试对于创建高质量的 UI 至关重要。在模块化系统中,微小的调整可能会导致重大的回归。到目前为止,我们已经遇到了三种类型的测试
-
手动测试 依赖于开发者手动查看组件以验证其正确性。它们帮助我们在构建时进行组件外观的健全性检查。
-
使用 a11y addon 进行可访问性测试,验证组件是否对所有人可访问。它们非常适合让我们收集有关有特定类型残疾的人如何使用我们的组件的信息。
-
使用 play 函数进行组件测试,验证组件在交互时是否按预期运行。它们非常适合测试组件在使用时的行为。
“但是,它看起来对吗?”
不幸的是,仅靠上述测试方法不足以防止 UI 错误。UI 很难测试,因为设计是主观和细致入微的。手动测试,顾名思义,是手动的。其他 UI 测试,例如快照测试,会触发过多的误报,而像素级单元测试的价值很低。一个完整的 Storybook 测试策略还包括视觉回归测试。
Storybook 的可视化测试
视觉回归测试,也称为可视化测试,旨在捕获外观上的变化。它们的工作原理是捕获每个 story 的屏幕截图,并将它们与 commit-to-commit 进行比较以显示变化。它非常适合验证图形元素,如布局、颜色、大小和对比度。
Storybook 是一个用于视觉回归测试的绝佳工具,因为每个 story 本质上都是一个测试规范。每次我们编写或更新一个 story 时,我们都会免费获得一个规范!
有几种用于视觉回归测试的工具。我们推荐 Chromatic,这是一个由 Storybook 维护者制作的免费发布服务,它在闪电般快速的云浏览器环境中运行视觉测试。它还允许我们在线发布 Storybook,正如我们在上一章中看到的那样。
捕获 UI 更改
视觉回归测试依赖于将新渲染的 UI 代码的图像与基线图像进行比较。如果捕获到 UI 更改,我们将收到通知。
让我们通过调整 Task
组件的背景来了解它是如何工作的。
首先为此更改创建一个新分支
git checkout -b change-task-background
将 src/components/Task.vue
更改为以下内容
<template>
<div :class="classes">
<label
:for="'checked' + task.id"
:aria-label="'archiveTask-' + task.id"
class="checkbox"
>
<input
type="checkbox"
:checked="isChecked"
disabled
:name="'checked' + task.id"
:id="'archiveTask-' + task.id"
/>
<span class="checkbox-custom" @click="archiveTask" />
</label>
<label :for="'title-' + task.id" :aria-label="task.title" class="title">
<input
type="text"
readonly
:value="task.title"
:id="'title-' + task.id"
name="title"
placeholder="Input title"
+ style="background-color: red" />
/>
</label>
<button
v-if="!isChecked"
class="pin-button"
@click="pinTask"
:id="'pinTask-' + task.id"
:aria-label="'pinTask-' + task.id"
>
<span class="icon-star" />
</button>
</div>
</template>
这会为项目产生新的背景颜色。
添加文件
git add .
提交它
git commit -m "change task background to red"
并将更改推送到远程仓库
git push -u origin change-task-background
最后,打开你的 GitHub 仓库,并为 change-task-background
分支打开一个拉取请求。
为你的拉取请求添加描述性文本,然后单击 Create pull request
。单击页面底部的“🟡 UI Tests”PR 检查。
它将向你展示你的提交捕获的 UI 更改。
有很多更改!Task
是 TaskList
和 Inbox
的子组件的组件层级结构意味着一个小的调整会像滚雪球一样变成重大的回归。这种情况正是开发者除了其他测试方法之外还需要视觉回归测试的原因。
审查更改
视觉回归测试确保组件不会意外更改。但这仍然取决于我们来确定更改是否是有意的。
如果更改是有意的,我们将需要更新基线,以便将未来的测试与 story 的最新版本进行比较。如果更改是无意的,则需要修复它。
由于现代应用程序是由组件构建的,因此我们在组件级别进行测试非常重要。这样做有助于我们查明更改的根本原因,即组件,而不是对更改的症状做出反应:屏幕和复合组件。
合并更改
当我们完成审查后,我们就可以放心地合并 UI 更改了——知道更新不会意外引入错误。如果你喜欢新的 red
背景,请接受更改。如果不是,请恢复到之前的状态。
Storybook 帮助我们构建组件;测试帮助我们维护它们。本教程涵盖四种类型的 UI 测试:手动、可访问性、交互和视觉回归。你可以通过将后三种添加到我们刚刚完成设置的 CI 中来自动化它们,它帮助我们交付组件,而无需担心隐藏的错误。整个工作流程如下图所示。