可视化测试

没有测试，Storybook 教程是不完整的。测试对于创建高质量的 UI 至关重要。在模块化系统中，微小的调整可能导致重大的回归。到目前为止，我们已经遇到了三种类型的测试

• 手动测试 依赖于开发人员手动查看组件以验证其正确性。 它们帮助我们在构建时检查组件外观的合理性。

• 使用 a11y 插件进行的 辅助功能测试 验证组件是否对所有人可访问。 它们非常适合让我们收集有关有特定类型残疾的人如何使用我们的组件的信息。

• 使用 play 功能进行的 组件测试 验证组件在与之交互时的行为是否符合预期。 它们非常适合测试组件在使用时的行为。

“但是它看起来对吗？”

不幸的是，仅靠上述测试方法不足以防止 UI 错误。 UI 很难测试，因为设计是主观和细致的。 手动测试，嗯，是手动的。 其他 UI 测试（例如快照测试）会触发过多的误报，而像素级单元测试的价值很低。 完整的 Storybook 测试策略还包括视觉回归测试。

Storybook 的可视化测试

视觉回归测试，也称为可视化测试，旨在捕捉外观上的变化。 它们的工作原理是捕获每个 story 的屏幕截图，并将它们与 commit-to-commit 进行比较以显示更改。 它非常适合验证图形元素，如布局、颜色、大小和对比度。

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 分支打开一个 pull request。

在您的 pull request 中添加描述性文本，然后单击 Create pull request。 单击页面底部的“🟡 UI Tests”PR 检查。

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

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

查看更改

视觉回归测试确保组件不会意外更改。 但仍然由我们来确定更改是有意的还是无意的。

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

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

合并更改

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

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