可视化测试
任何 Storybook 教程都不会缺少测试部分。测试对于创建高质量 UI 至关重要。在模块化系统中,微小的调整可能会导致严重的回归。到目前为止,我们遇到了三种类型的测试:
-
手动测试依赖开发者手动检查组件以验证其正确性。它们在我们构建时帮助我们进行组件外观的健全性检查。
-
可访问性测试使用 a11y 插件验证组件对所有人来说都是可访问的。它们非常适合帮助我们收集关于有特定类型残疾的人如何使用我们的组件的信息。
-
组件测试使用 play 函数验证组件在交互时表现是否符合预期。它们非常适合测试组件在使用时的行为。
“但它看起来对吗?”
不幸的是,上述测试方法本身不足以防止 UI 错误。UI 难以测试,因为设计是主观且细致入微的。手动测试就是手动进行的。其他 UI 测试,例如快照测试,会产生太多误报,而像素级单元测试价值不高。一套完整的 Storybook 测试策略还包括可视化回归测试。
Storybook 的可视化测试
可视化回归测试,也称为可视化测试,旨在捕获外观变化。它们通过捕获每个故事的屏幕截图,并逐个提交进行比较,以发现变化。这对于验证布局、颜色、大小和对比度等图形元素非常完美。
Storybook 是一个出色的可视化回归测试工具,因为每个故事本质上就是一个测试规范。每次我们编写或更新一个故事,我们都能免费获得一个规范!
有几种可视化回归测试工具。我们推荐 Chromatic,这是一个由 Storybook 维护者制作的免费发布服务,它在闪电般快速的云浏览器环境中运行可视化测试。它还允许我们将 Storybook 在线发布,正如我们在上一章中所见。
捕获 UI 变化
可视化回归测试依赖于将新渲染的 UI 代码的图像与基准图像进行比较。如果捕获到 UI 变化,我们将收到通知。
让我们通过调整 Task
组件的背景来了解它是如何工作的。
首先为此更改创建一个新分支
git checkout -b change-task-background
将 src/app/components/task.component
更改为以下内容
@Component({
selector: 'app-task',
standalone: false,
template: `
<div class="list-item {{ task?.state }}">
<label
[attr.aria-label]="'archiveTask-' + task?.id"
for="checked-{{ task?.id }}"
class="checkbox"
>
<input
type="checkbox"
disabled="true"
[defaultChecked]="task?.state === 'TASK_ARCHIVED'"
name="checked-{{ task?.id }}"
id="checked-{{ task?.id }}"
/>
<span class="checkbox-custom" (click)="onArchive(task?.id)"></span>
</label>
<label
[attr.aria-label]="task?.title + ''"
for="title-{{ task?.id }}"
class="title"
>
<input
type="text"
[value]="task?.title"
readonly="true"
id="title-{{ task?.id }}"
name="title-{{ task?.id }}"
placeholder="Input title"
+ style="background-color: red;"
/>
</label>
<button
*ngIf="task?.state !== 'TASK_ARCHIVED'"
class="pin-button"
[attr.aria-label]="'pinTask-' + task?.id"
(click)="onPin(task?.id)"
>
<span class="icon-star"></span>
</button>
</div>
`,
})
这将为该项设置一个新的背景颜色。
添加文件
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
和 InboxScreen
的子组件,这意味着微小的调整会像滚雪球一样导致严重的回归。这种情况正是开发者除了其他测试方法外,还需要可视化回归测试的原因。
查看变化
可视化回归测试确保组件不会意外改变。但确定这些变化是故意的还是意外的仍取决于我们。
如果变化是故意的,我们需要更新基准,以便未来的测试与故事的最新版本进行比较。如果变化是意外的,则需要修复。
由于现代应用程序由组件构成,因此在组件级别进行测试非常重要。这样做有助于我们找出变化的根本原因(即组件),而不是对变化的症状(屏幕和复合组件)做出反应。
合并更改
查看完成后,我们可以放心地合并 UI 更改——因为我们知道更新不会意外引入 bug。如果您喜欢新的 red
背景,请接受更改。如果不喜欢,请恢复到之前的状态。
Storybook 帮助我们构建组件;测试帮助我们维护组件。本教程涵盖了四种类型的 UI 测试:手动测试、可访问性测试、交互测试和可视化回归测试。您可以通过将后三种测试添加到 CI 中来实现自动化,正如我们刚刚设置完成的那样,这有助于我们在发布组件时无需担心隐藏的 bug。整个工作流程如下图所示。