可视化测试

没有测试，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.tsx 更改为以下内容

import type { TaskData } from '../types';

type TaskProps = {
  /** Composition of the task */
  task: TaskData;
  /** Event to change the task to archived */
  onArchiveTask: (id: string) => void;
  /** Event to change the task to pinned */
  onPinTask: (id: string) => void;
};


export default function Task({
  task: { id, title, state },
  onArchiveTask,
  onPinTask,
}: TaskProps) {
  return (
    <div className={`list-item ${state}`}>
      <label
        htmlFor={`archiveTask-${id}`}
        aria-label={`archiveTask-${id}`}
        className="checkbox"
      >
        <input
          type="checkbox"
          disabled={true}
          name="checked"
          id={`archiveTask-${id}`}
          checked={state === "TASK_ARCHIVED"}
        />
        <span className="checkbox-custom" onClick={() => onArchiveTask(id)} />
      </label>

      <label htmlFor={`title-${id}`} aria-label={title} className="title">
        <input
          type="text"
          value={title}
          readOnly={true}
          name="title"
          id={`title-${id}`}
          placeholder="Input title"
+         style={{ backgroundColor: 'red' }}
        />
      </label>
      {state !== "TASK_ARCHIVED" && (
        <button
          className="pin-button"
          onClick={() => onPinTask(id)}
          id={`pinTask-${id}`}
          aria-label={`pinTask-${id}`}
          key={`pinTask-${id}`}
        >
          <span className={`icon-star`} />
        </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 和 Inbox 的子组件，这种组件层级关系意味着一个小的调整会像滚雪球一样引发严重的回归。这种情况正是开发者除了其他测试方法外，还需要可视化回归测试的原因。

审查更改

可视化回归测试确保组件不会意外改变。但变化是有意还是无意的，仍然需要我们来判断。

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

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

合并更改

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

Storybook 帮助我们构建组件；测试帮助我们维护它们。本教程涵盖了四种类型的 UI 测试：人工测试、可访问性测试、交互测试和可视化回归测试。正如我们刚刚设置的那样，你可以通过将后三种测试添加到 CI 中来实现自动化，这有助于我们发布组件而不必担心潜藏的 bug。完整的工作流程如下所示。