前端测试新手？从金字塔顶端开始！

一种从前端测试世界获得即时结果（和满意度）的更简单的方法。

我正在 GitHub 上开展一个大型UI 测试最佳实践项目，我分享这篇文章是为了传播它并获得直接反馈。

当你是一位经验丰富的测试人员时，编写测试套件并不难。但学习如何正确测试、测试哪些内容、避免哪些内容、选择哪种测试等等，就不那么容易了。

测试在初期成本很高。一切都是新的，你尝试实现的示例无法运行，你不清楚测试失败的原因，以及它与你的代码有何关联等等。

我们都知道测试金字塔，通常我们从底部开始

标准测试金字塔方法：从下到上。

从金字塔底部开始是合理的。从单元测试开始更容易，因为它们速度快，不需要复杂的上下文或工具，一个“单元”（无论你如何理解“单元”：一个函数、一个组件等等）只包含几行代码，而且通常只有一些依赖项（或者根本没有），等等。

这种方法最大的缺点是什么？本质上就是信心。

测试的关键在于信心，以及高信心但缓慢的测试和低信心但快速的测试之间的权衡。

如果你是测试领域的新手，那么“信心”这个词可能在你的脑海中不太清晰。那么，如果测试通过，你如何确保你正在开发的应用程序能够正常工作呢？这就是测试信心。

为什么单元测试的可信度这么低？举几个例子：

• 如果该isValidEmail功能通过测试，您确定您的前端应用程序的注册表单可以正常工作吗？

• 如果InputReact 组件通过了测试，你确定注册表单也能正常工作吗？

• 如果整个RegisterForm组件通过测试，您确定用户可以注册吗？

答案是否定的。整个应用程序是由许多相互集成的单元组成的，这还不包括一些表现性（CSS）问题，这些问题可能会因为 z-index 较高的图像覆盖了提交按钮而阻止用户注册。

再次说说测试新手（就像我两年前那样）缺乏的经验：所有新事物都需要很大的认知负荷，你无法同时面对太多新事物。同时面对常规的应用开发、新的测试主题、单元测试和 UI 测试（后两者需要不同的工具和精力）是很困难的。

看一下来自JavaScript 和 Node.js 测试最佳实践项目的详尽图片：

由Yoni Goldberg提供，请访问testjavascript.com并为JavaScript 和 Node.js 测试最佳实践存储库添加一颗星。

对于经验丰富的开发人员来说确实如此，而当您第一次接触测试世界时，情况会更糟。

从下到上的方法结果

你不可避免地会把大部分注意力放在金字塔的底层——单元测试上。你将要编写的一堆测试让你熟悉测试的世界，但却缺乏信心。你可能会问自己

• “我编写的测试有什么好处？”

• “我花了一些时间进行单元测试，但应用程序像以前一样崩溃了，测试会自行结束吗？”

• “说实话，我现在比开始测试之前有更多的疑虑……”

自下而上的方法不可避免地会让你专注于单元测试。

问题不在于你，而在于对初学者来说测试的类型错误！

我建议的解决方案是什么？从顶层开始，首先专注于 UI 测试！

首先，什么是 UI 测试（也称为功能测试、端到端测试等）？它本质上是一个脚本，它会打开一个真实的浏览器并与 DOM 元素进行交互，就像真实的终端用户一样。有些视频比几百个单词更能说明问题。

在上面的视频中，你可以看到一个真实的浏览器加载了整个前端应用程序并与之交互。其优点如下：

• 你的应用程序在与最终用户（浏览器）相同的环境中进行测试，这意味着更高的可信度。即使你只编写一个 UI 测试，也比编写一百个单元测试更有信心。

• 测试路径（用户执行的步骤，如“注册”、“创建新帖子”等）与最终用户必须执行的步骤相同，这意味着（对您而言）可以降低认知负荷，以了解您真正测试的内容

• 老实说，自动化浏览器比自动化终端更有趣😁

• UI 测试最适合你日常工作的大多数中小型项目。从落地页到小型 CMS：所有这些项目都至少需要一些 UI 测试，但你可以根据测试信心和需要交付的内容，在单元测试方面略胜一筹。你们中有些人在 Facebook、Spotify、Netflix 等公司工作，这些公司的产品需要严格的测试策略、代码覆盖率要求等。更概括地说：如果你在中大型产品公司工作，你可能不需要这篇文章，因为测试是公司文化的核心🎉

当然也有一些缺点，但我稍后会列出来。以下是我建议的方法：

自上而下的方法。

自上而下的方法是否会强制执行不良测试做法？

这篇文章并非探讨最佳实践或坏习惯（文章末尾有丰富的资源列表），而是探讨如何让前端开发者新手也能在测试领域获得成功。我的目标是提供一种更实用的方法，让开发者能够享受测试带来的优势，同时避免留下比以前更多的疑虑。

如果 UI 测试如此神奇，为什么还要存在其他类型的测试？

这就是重点！请注意，我并不反对单元测试！每种测试都很重要，不同的测试会提供不同的反馈！从金字塔顶端攀登的开发人员足以热爱整个测试世界。

然后，您将发现高级UI 测试的局限性：

• 它们很慢：我知道上面的视频让你觉得它们超级快，但事实并非如此。当你有五个、十个、二十个 UI 测试时，它们很快，但当你有数百个 UI 测试，并且它们需要几分钟时，你就会开始问自己如何才能改善这种情况。

• 它们主要提供一些高层次的反馈：如果表单的提交按钮不起作用，是什么 bug？有很多可能的原因，但 UI 测试无法排除其中一些。

• 它们会渲染整个应用，如果你只想测试一些小部分，这可能会很麻烦。有些你需要测试的极端情况，在整个应用中根本无法复制。

解决以上所有问题的答案是：使用测试金字塔向下！如果你达到了降低测试需求的目的，那就太棒了！这就是这篇文章的目标！

考虑两种方法的结果：

• 从下到上：你对编写的单元测试的实用性有疑问，并且你不明白这些测试如何帮助你提高测试信心

• 从上到下：你有一些可靠的测试，最终需要沿着测试金字塔向下走。如果你不需要向下走，说明你的项目很小，不需要再进行任何测试。

我们（我和Jaga Santagostino ）在ReactJSDay 2019 会议的React 测试课程中采用了自上而下的方法。

告诉我有关 UI 测试的更多信息

为什么测试金字塔把 UI 测试放在最顶端？嗯，因为它们通常很贵（就时间和编写成本而言）。既然它们这么贵，为什么我建议从 UI 测试开始呢？

• 首先：UI 测试是一个通用术语，我们必须将其分为E2E 测试和 UI 集成测试。E2E 测试非常昂贵，因为它们需要你与团队其他成员合作，需要一个可以运行的后端和数据库，而且容易受到后端资源和网络速度缓慢的影响。UI
  集成测试更可行，因为所有 AJAX 请求都被存根（替换为静态 JSON 文件），因此你不需要一个可以运行的后端，而且它们快速、可靠、可预测，并且允许你独立工作。在进行 E2E 测试之前，先从 E2E 测试开始。

• 现在已经存在成熟的工具：不要考虑 Selenium 或 Puppeteer（通用浏览器自动化工具），而要使用Cypress或TestCafé（第一个对于初学者来说更容易，但两者都有效）。

• 遵循一些基本的最佳实践，例如避免测试睡眠和避免完美主义。如果这篇文章让你感兴趣，也请阅读“将 Cypress 作为你的主要开发浏览器”。

希望本文对您有所帮助。欢迎您留下反馈，或分享您在探索精彩测试世界时的经验。