可视化测试

任何 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.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 更改，因为知道更新不会意外引入错误。如果你喜欢新的 红色 背景，就接受更改。如果不是，则恢复到先前的状态。

Storybook 帮助我们构建组件；测试帮助我们维护它们。本教程涵盖四种 UI 测试类型：手动、无障碍、交互和视觉回归。你可以将后三种自动化添加到 CI 中，就像我们刚刚设置的那样，这有助于我们在发布组件时不必担心隐藏的 bug。整个工作流程如下图所示。