返回UI 测试手册
React
章节
  • 简介
  • 视觉
  • 组成
  • 交互
  • 可访问性
  • 用户流程
  • 自动化
  • 工作流程
  • 总结

UI 测试指南

一种不会拖慢你的测试工作流程

找到测试 UI 不同部分的工具很容易。但如何将它们组合成高效的工作流程却很棘手。如果组合不当,就会演变成维护的噩梦。

我们的工作流程通过将 stories 重用为测试用例来减轻维护负担。此外,我们还可以在组件级别进行测试,从而更快地发现 bug。

本章将通过增加删除任务的功能来演示整个 UI 测试工作流程。

构建

Task 组件已经允许用户编辑、置顶和归档任务。我们将添加一个删除按钮,并将其连接到应用程序状态,以添加删除功能。

对于此演示,我们直接跳到准备测试的阶段。下载更新后的文件,并将其放在 /src 目录中

视觉与组成测试

首先,我们要确保更新后的 UI 样式与规范一致。Task 组件现在需要 onDeleteTask prop 来处理删除操作。让我们在 Task stories 中将其模拟为一个 action。

复制
src/components/Task.stories.jsx
import Task from './Task';

export default {
  component: Task,
  title: 'Task',
  argTypes: {
    onArchiveTask: { action: 'onArchiveTask' },
    onTogglePinTask: { action: 'onTogglePinTask' },
    onEditTitle: { action: 'onEditTitle' },
+   onDeleteTask: { action: 'onDeleteTask' },
  },
};

开发期间

你可以使用 Storybook 专注于 Task 组件,而无需启动整个应用程序。然后遍历其所有 stories,手动验证其外观。

PR 检查

对 Task UI 进行的微调可能会导致使用它的其他组件(TaskList 和 InboxScreen)发生意外更改。使用 Chromatic 运行视觉测试可以捕获这些更改。它还能确保所有内容仍然正确连接。

创建拉取请求时,Chromatic 会自动触发。完成后,会显示一个 diff 供你审阅。在此例中,更改是故意的。按下接受按钮更新基准线。

可访问性测试

开发期间

开发期间在 Storybook 中运行可访问性检查。A11y 插件 使用 Axe 审计当前激活的 story,并在插件面板中显示报告。快速浏览一下即可确认我们的 stories 都没有任何违规。

PR 检查

为了捕获回归问题,你需要在所有组件上运行测试。你可以通过将 stories 导入测试文件,然后使用 jest-axe 运行可访问性审计来实现。所有违规都将报告回 PR 页面。

组件测试

用户可以通过点击 垃圾桶 按钮删除任务,我们需要添加一个测试来验证此行为。

开发期间

开发期间,使用 InboxScreen stories 手动验证交互。如果符合预期,你可以使用 play function 添加组件测试。

复制
src/InboxScreen.stories.jsx
// ... code omitted for brevity ...

export const DeleteTask = {
  parameters: {
    ...Default.parameters,
  },
  play: async ({ canvasElement }) => {
    const canvas = within(canvasElement);
    const getTask = (id) => canvas.findByRole('listitem', { name: id });

    const itemToDelete = await getTask('task-1');
    const deleteButton = await findByRole(itemToDelete, 'button', {
      name: 'delete',
    });

    // Click the delete button
    await userEvent.click(deleteButton);
    await expect(canvas.getAllByRole('listitem').length).toBe(5);
  },
};

运行 yarn run test-storybook 确认所有测试都已通过。注意 Jest 如何在 watch 模式下运行,并且只执行与更改文件相关的测试。

PR 检查

创建拉取请求时,Github Actions 将运行测试执行器,并通过 PR 检查报告状态。

用户流程测试

最后,你需要运行端到端测试(E2E tests),以确保所有关键用户流程都按预期工作。

开发期间

这项新功能不影响认证流程。因此,你可以在 CI 服务器上运行 Cypress。只有在添加或更新测试时,才需要在开发期间运行有针对性的端到端测试(E2E tests)。

PR 检查

就像所有其他测试一样,Github actions 也会使用 Cypress 运行端到端测试(E2E tests)。

你的旅程开始了

UI 测试手册 重点介绍了专业前端团队使用的测试策略。这些测试就像应用的健康检查,验证从视觉外观到 UI 逻辑的一切,甚至能检测集成问题。更重要的是,你可以通过使用持续集成自动测试每个提交来减少 bug。

最后一章总结了完整的示例代码、有用的资源以及开发者常问的问题。

让你的代码与本章保持同步。在 GitHub 上查看 f330642。
这份免费指南对你有帮助吗?发推文点赞,帮助其他开发者找到它。
下一章
总结
事半功倍
✍️ 在 GitHub 上编辑 – 欢迎 PR!
加入社区
6,975名开发者及更多
为何为何选择 Storybook组件驱动型 UI
开源软件
Storybook - Storybook 中文

特别感谢 Netlify CircleCI