返回至可视化测试手册
React
章节
  • 简介
  • 组件浏览器
  • 工作流程
  • 可视化 TDD
  • 自动化
  • 结论

工作流程

用于构建组件的测试驱动工作流程

用户界面开发一直以来都定义模糊。用户界面的主观性导致了临时的开发工作流程和缺陷百出的用户界面。本章将分享专业团队如何以严谨的可视化测试驱动方式构建用户界面。

测试驱动开发

在我们开始之前,让我们回顾一下测试驱动开发 (TDD),这是一种流行的工程实践。TDD 背后的核心思想是,您在开发要测试的功能之前编写测试。

  1. 为您的代码构建一组自动化单元测试
  2. 编写代码本身以“使测试通过”

TDD 允许您清楚地思考您的代码需要做什么,从具体的输入方面来看(对于组件,我们将这些称为“状态”)。这样,您可以覆盖模块的所有用例。

让我们看一个例子。假设我们有一个 relativize 函数,它可以将原始日期对象转换为 “2 周前” 形式的相对日期格式。概述您想要覆盖的所有各种输入类型非常简单。然后,每次您认为自己在解决方案方面取得进展时,只需点击“测试”按钮即可。

您的测试框架允许您在隔离状态下运行 relativize 函数,而无需为整个应用程序提供输入,仅用于测试该部分。

然而,在开发用户界面时,TDD 就显得不足,因为很难提前定义测试,模块难以隔离,并且输出是主观的。通过隔离地可视化测试组件,可以解决这些缺点。

可视化测试

用户界面测试的棘手之处在于,仅凭代码无法验证相关的视觉细节。可视化测试通过以快速且集中的方式让人的判断参与进来,从而绕过了这一点。

可视化测试工作流程

在实践中,可视化测试使用 Storybook 来“可视化地”测试组件在一组定义的测试状态下的表现。可视化测试与任何其他类型的测试共享相同的设置、执行和拆卸步骤,但验证步骤则由用户负责。

test do
  setup
  execute 👈 Storybook renders stories
  verify 👈 you look at stories
  teardown
end

随后,任何回归都会通过自动捕获和比较图像快照来捕获。

test do
  setup
  execute 👈 Storybook renders stories
  verify 👈 capture image snapshots and compare them to baselines
  teardown
end

在两种情况下都使用相同的测试用例,只是验证方法有所不同。

如何编写可视化测试用例

现在让我们关注第一个场景。在 Storybook 中,测试就像渲染 React 元素一样简单。要编写可视化测试用例,即 Storybook 术语中的 “story”,我们概述了我们感兴趣的组件的状态。下面的代码示例展示了如何为 InboxTaskSnoozedTaskPinnedTask 编写可视化测试。

复制
src/components/Task.stories.ts
import type { Meta, StoryObj } from '@storybook/react';

import Task from './Task';

const meta: Meta = {
  component: Task,
  title: 'Task',
} satisfies Meta<typeof Task>;

export default meta;
type Story = StoryObj<typeof meta>;

export const InboxTask: Story = {
  args: {
    task: {
      id: '1',
      title: 'Test Task',
      state: 'TASK_INBOX',
      updatedAt: new Date(2023, 0, 1, 9, 0),
      boardName: 'On Test Board',
    },
  },
};

export const SnoozedTask: Story = {
  args: {
    task: {
      // Shaping the stories through args composition.
      ...InboxTask.args?.task,
      state: 'TASK_SNOOZED',
    },
  },
};

export const PinnedTask: Story = {
  args: {
    task: {
      // Shaping the stories through args composition.
      ...InboxTask.args?.task,
      state: 'TASK_PINNED',
    },
  },
};

在 Storybook 中,Task 及其变体将显示在侧边栏中。这对应于测试周期的“执行”阶段;“验证”阶段我们在 Storybook 中用肉眼完成。

对于测试用户界面,人工验证是一种务实的方法,因为它对组件中不影响视觉外观的代码更改具有鲁棒性。此外,由于我们只需要提前编写输入并目视检查输出,因此我们正在自动以 TDD 风格构建用户界面。

学习可视化测试驱动开发

如果您正在从经过深思熟虑的设计构建应用程序,则很可能有一组在设计工件中嵌入了输入和输出的、规范良好的组件。将此 “设计规范” 与可视化测试过程配对,您就可以运行与 TDD 完全类似的流程。

在下一章中,我们将应用到目前为止所学的知识,通过使用可视化 TDD 编写示例组件。

这个免费指南对您有帮助吗?发推文以示赞赏并帮助其他开发者找到它。
下一章
可视化 TDD
编写您的第一个可视化测试
✍️ 在 GitHub 上编辑 – 欢迎提交 PR!
加入社区
6,721位开发者以及更多
为什么为什么选择 Storybook组件驱动的 UI
开源软件
Storybook - Storybook 中文

特别感谢 Netlify CircleCI