前端测试的新方法，有关SafeTest，2024年最新一起“干完”这份300页1000道面试题

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

传统上，UI 测试是通过单元测试或集成测试（也称为端到端 E2E 测试）进行的。然而，这些方法中的每一种都提出了独特的权衡：你必须在控制测试夹具（test fixture）和设置，或控制测试驱动器之间进行选择。

例如，当使用react-testing-library（一个单元测试解决方案）（https://testing-library.com/docs/react-testing-library/intro/）时，你可以完全控制要呈现的内容以及底层服务和导入的行为方式。然而，你却失去了与实际页面交互的能力，这可能会导致无数的痛点：

• 难以与复杂的 UI 元素（例如 组件）进行交互。
• 无法测试 CORS 设置或 GraphQL 调用。
• 缺乏对影响按钮可点击性的 z-index 问题的可见性。
• 测试的编写和调试复杂且不直观。

相反，使用 Cypress 或 Playwright 等集成测试工具可以提供对页面的控制，但会牺牲为应用程序检测引导代码的能力。这些工具通过远程控制浏览器访问 URL 并与页面交互来进行操作。这种方法有其自身的一系列挑战：

• 如果不实施自定义网络层 API 重写规则，则很难调用替代 API 端点。
• 无法对间谍/模拟（spies/mocks）进行断言或在应用程序内执行代码。
• 测试诸如黑暗模式之类的内容需要单击主题切换器或了解要覆盖的本地存储机制。
• 无法测试应用程序的各个部分，例如，如果某个组件仅在单击按钮并等待 60 秒计时器倒计时后才可见，则测试将需要运行这些操作，并且至少需要一分钟长。

认识到这些挑战后，Cypress（https://docs.cypress.io/guides/component-testing/overview）和 Playwright（https://playwright.dev/docs/test-components）提供的端到端组件测试等解决方案应运而生。

虽然这些工具试图纠正传统集成测试方法的缺点，但由于其架构，它们还存在其他限制。他们使用引导代码启动开发服务器来加载所需的组件和/或设置代码，这限制了他们处理可能具有 OAuth 或复杂构建管道的复杂企业应用程序的能力。此外，更新 TypeScript 的使用可能会破坏你的测试，直到 Cypress/Playwright 团队更新他们的运行程序。

什么是SafeTest ？****

SafeTest 旨在通过一种新颖的 UI 测试方法来解决这些问题。主要思想是在我们的应用程序引导阶段添加一段代码，注入钩子来运行我们的测试。

Safetest 是一个功能强大的 UI 测试库，它结合了 Playwright、Jest/Vitest 和 React，为应用程序和组件测试提供了强大的端到端测试解决方案。有了 Safetest，您可以轻松测试应用程序的功能和外观，确保应用程序按预期运行，并在所有设备上都美观大方。

Safetest 与您现有的开发环境集成，并提供熟悉、易用的 API 用于创建和管理测试，从而为您提供无缝的测试体验。

https://github.com/kolodny/safetest

请注意，这种工作方式对应用程序的常规使用没有可衡量的影响，因为 SafeTest 仅在运行测试时利用延迟加载来动态加载测试（在 README 示例中，测试根本不在生产包中）。一旦到位，我们就可以使用 Playwright 运行常规测试，从而实现我们测试所需的理想浏览器控制。

这种方法还解锁了一些令人兴奋的功能：

• 深层链接到特定测试，无需运行节点测试服务器。
• 浏览器和测试（节点）上下文之间的双向通信。
• 访问 Playwright 附带的所有 DX 功能（不包括 @playwright/test 附带的功能）。
• 测试视频录制、跟踪查看和暂停页面功能以尝试不同的页面选择器/操作。
• 能够对节点中浏览器中的间谍进行断言，匹配浏览器中调用的快照。

使用SafeTest测试示例

SafeTest 的设计让之前进行过 UI 测试的任何人都感到熟悉，因为它利用了现有解决方案的最佳部分。以下是如何测试整个应用程序的示例：

import { describe, it, expect } from ‘safetest/jest’;
import { render } from ‘safetest/react’;

describe(‘my app’, () => {
it(‘loads the main page’, async () => {
const { page } = await render();

await expect(page.getByText(‘Welcome to the app’)).toBeVisible();
expect(await page.screenshot()).toMatchImageSnapshot();
});
});

我们可以轻松地测试特定组件：

import { describe, it, expect, browserMock } from ‘safetest/jest’;
import { render } from ‘safetest/react’;

describe(‘Header component’, () => {
it(‘has a normal mode’, async () => {
const { page } = await render(

);

await expect(page.getByText(‘Admin’)).not.toBeVisible();
});

it(‘has an admin mode’, async () => {
const { page } = await render(

);

await expect(page.getByText(‘Admin’)).toBeVisible();
});

it(‘calls the logout handler when signing out’, async () => {
const spy = browserMock.fn();
const { page } = await render(

);

await page.getByText(‘logout’).click();
expect(await spy).toHaveBeenCalledWith();
});
});

利用Overrides（重写）

SafeTest利用React Context允许在测试期间重写值。举例说明其工作原理，假设我们在组件中使用了 fetchPeople 函数：

import { useAsync } from ‘react-use’;
import { fetchPerson } from ‘./api/person’;

export const People: React.FC = () => {
const { data: people, loading, error } = useAsync(fetchPeople);

if (loading) return ;
if (error) return ;
return

;
}

我们可以修改 People 组件以使用 Override：

import { fetchPerson } from ‘./api/person’;
+import { createOverride } from ‘safetest/react’;

+const FetchPerson = createOverride(fetchPerson);

export const People: React.FC = () => {

• const fetchPeople = FetchPerson.useValue();
  const { data: people, loading, error } = useAsync(fetchPeople);

if (loading) return ;
if (error) return ;
return

;
}

现在，在我们的测试中，我们可以覆盖此调用的响应：

const pending = new Promise(r => { /* Do nothing */ });
const resolved = [{name: ‘Foo’, age: 23], {name: ‘Bar’, age: 32]}];
const error = new Error(‘Whoops’);

describe(‘People’, () => {
it(‘has a loading state’, async () => {
const { page } = await render(
<FetchPerson.Override with={() => () => pending}>

</FetchPerson.Override>
);

await expect(page.getByText(‘Loading’)).toBeVisible();
});

it(‘has a loaded state’, async () => {
const { page } = await render(
<FetchPerson.Override with={() => async () => resolved}>

</FetchPerson.Override>
);

await expect(page.getByText(‘User: Foo, name: 23’)).toBeVisible();
});

it(‘has an error state’, async () => {
const { page } = await render(
<FetchPerson.Override with={() => async () => { throw error }}>

</FetchPerson.Override>
);

await expect(page.getByText(‘Error getting users: “Whoops”’)).toBeVisible();
});
});

渲染函数还接受一个将传递给初始应用程序组件的函数，允许在应用程序中的任何位置注入任何所需的元素：

it(‘has a people loaded state’, async () => {
const { page } = await render(app =>
<FetchPerson.Override with={() => async () => resolved}>
{app}
</FetchPerson.Override>
);
await expect(page.getByText(‘User: Foo, name: 23’)).toBeVisible();
});

通过overrides，我们就可以编写复杂的测试用例，例如确保一个结合了来自 /foo、/bar和 /baz 的 API 请求的服务方法，只对失败的 API 请求采用正确的重试机制，并仍能正确映射返回值。因此，如果 /bar 需要3次尝试才能解决，该方法将总共调用5次 API。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-7pTjeVdF-1713468600955)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！