可视化测试

没有测试，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/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 分支打开一个拉取请求。

为您的拉取请求添加描述性文本，然后单击“创建拉取请求”。单击页面底部的“🟡 UI Tests”PR 检查。

它将向您显示您的提交捕获的 UI 更改。

有很多更改！组件层次结构中，Task 是 TaskList 和 InboxScreen 的子组件，这意味着一个小小的调整会像滚雪球一样变成重大的回归。这种情况正是开发人员除了其他测试方法之外还需要视觉回归测试的原因。

审查更改

视觉回归测试确保组件不会意外更改。但这仍然取决于我们来确定更改是否是故意的。

如果更改是故意的，我们需要更新基线，以便将未来的测试与最新版本的 story 进行比较。如果更改是无意的，则需要修复。

由于现代应用程序是由组件构建的，因此我们在组件级别进行测试非常重要。这样做有助于我们查明更改的根本原因，即组件，而不是对更改的症状做出反应：屏幕和复合组件。

合并更改

当我们完成审查后，我们就可以放心地合并 UI 更改了——知道更新不会意外引入错误。如果您喜欢新的 red 背景，请接受更改。如果不是，请恢复到之前的状态。

Storybook 帮助我们 构建 组件；测试帮助我们 维护 它们。本教程涵盖四种类型的 UI 测试：手动、可访问性、交互和视觉回归。您可以通过将后三者添加到我们刚刚完成设置的 CI 中来自动化它们，这有助于我们交付组件，而无需担心隐藏的错误。整个工作流程如下图所示。