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