可视化测试

任何 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 分支打开一个拉取请求（Pull Request）。

为你的拉取请求添加描述性文本，然后点击 Create pull request。点击页面底部的 "🟡 UI Tests" PR 检查。

它会显示你的提交所捕获的 UI 变化。

有很多变化！Task 是 TaskList 和 Inbox 的子组件这种组件层级关系意味着一个微小的调整会像滚雪球一样引发重大的回归。这种情况正是开发者除了其他测试方法之外还需要可视化回归测试的原因。

审查更改

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

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

由于现代应用程序由组件构建而成，因此在组件层面进行测试非常重要。这样做有助于我们确定变化的根本原因（即组件），而不是对变化的症状（即屏幕和组合组件）做出反应。

合并更改

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

Storybook 帮助我们构建组件；测试帮助我们维护它们。本教程中涵盖的四种 UI 测试类型是手动测试、快照测试、单元测试和可视化回归测试。你可以通过将后三种添加到 CI 中来自动化，就像我们刚刚完成设置一样，这有助于我们发布组件，而无需担心隐藏的 bug。整个工作流程如下图所示。