有效的前端测试

在IT行业这个发展更新速度很快的行业，只有不停止的学习，才不会被行业所淘汰。如果你是文章学习者，那么本文《有效的前端测试》就很适合你！本篇内容主要包括##content_title##，希望对大家的知识积累有所帮助，助力实战开发！

面试已经有一段时间了。在这个痛苦的过程中最突出的是，如果提出测试问题，面试就注定失败。这是因为我的经验主要是前端开发，而我待过的两家公司在前端测试方面都很差。

--- 如果想直接进入讨论请跳过---

从某种意义上说，我的缺乏是行业文化的副产品。前端测试一直是一件事，但十年前，公司结构已经将测试问题与开发过程分开。因此，我们有一个专门的 QA 团队，他们将为我们的开发人员编写 E2E/自动化测试。所以测试甚至没有出现在工作描述中。此外，小型初创公司的不幸事实是交付始终高于一切，因此由于测试会阻碍生产力，因此我们开发人员没有进行测试。我们甚至没有在存储库中安装任何测试库（Jasmine/Mocha/PhantomJS...）。

我在一家更大的公司找到了第二份工作（消费者平台团队有大约 150 名开发人员？）。然而，从本质上讲，并没有进行任何测试。每个团队（按结帐、忠诚度、注册等功能划分的团队）再次有专门的 QA 成员来编写这些 E2E 测试。一旦这种文化形成并且质量保证从预算中削减，就没有人接受它们，因为没有人可以向他们学习。我试图为我们的团队进行一些 E2E 测试，但留下的代码甚至无法正常工作，而且充满了明显的错误（很多 WTF）。再加上时间紧迫，测试又落后了。人们唯一一次谈论测试是实用函数和自定义反应钩子。

---讨论开始---

受到无测试文化的困扰，我至少必须想出一些我可以在面试中抽象地谈论测试的东西。我将跳过不测试样式或实现之类的常见废话。

请随意添加到讨论中。这影响了我至少 300 名过去的同事！

1.) 测试全局状态：
根据我的经验，最粗糙的功能之一是“如果发生这种情况，我们会自动为您执行此操作”类型的行为。例如，我拥有的一个应用程序是一个可高度配置的图形可视化仪表板。一项配置更改可能会导致其他配置也发生更改，具体取决于返回的数据以及未返回的数据。一些配置副作用并不直接。因此，您需要测试自动配置更改以及状态是否全面持久/未更改/一致。因此，如果您围绕此类行为进行测试，与 PM、经理、设计和 QA 团队保持一致是非常有价值的。

2.）不要花太多时间测试 UI 输入的完整性：
我看到很多教程都在谈论测试输入，例如当我在搜索栏中输入“泰勒·斯威夫特”并按 Enter 键时，我们的搜索功能将获得泰勒·斯威夫特作为输入。

这完全没有帮助。如果您的数据绑定被破坏，那么很明显您应该在开发时自己捕获它，或者它不能自动测试，因为某些东西阻碍了功能，例如搜索栏上方的不可见 div，因此用户无法输入搜索。

如果你是通过代码行付费的，那就继续吧:)

3.）测试输入作为输入的副作用是可取的：
与第二点相反，您需要测试对用户交互完全产生副作用的功能调用。例如，当用户单击按钮时，应调用请求来注册该用户操作以进行数据分析。这种与核心功能完全分离的副作用应该自动测试，这样我们就不会因一些无意的更改而措手不及。非核心副作用对于其他团队来说可能是至关重要的，我曾在其他团队之一中工作：D

那么如何构建这些测试需求呢？
让我们分解一下前端架构：MVC（你可以说你是 MVVM 或者什么不是，这并不重要）。

V - 视图 (html/jsx)： 这非常适合 E2E/无头浏览器测试，并且是行业标准。

C - 控制器（业务逻辑）：花一些时间确保功能正确。例如，如果您具有/抽象为纯函数，那么预期的输入输出过程是否仍然完好无损？有点行业标准，但人们通常不会费心将有状态函数变成纯函数并进行测试。

M - 模型（api 调用/状态）： 这是我最想关注的。您的（非渲染）状态应该是全局的并且每个概念都是单例的。这不是什么新想法，因为 Redux 基本上就是这样。然而，出于我们的测试目的，它不一定是 Flux。您可以拥有 jotai 原子，但您可以编写一个包装器，以便可以公开集中的 setter 函数进行测试。

应该在您的 api 调用/第三方库上执行类似的操作。它应该是全局的和单例的，以便您可以自信地测试“当我这样做时，是应用程序中进行的核心/非核心 api 调用”。以我有限的经验，这是在后端应用程序中例行完成的。它也应该在前端应用程序中完成。

这听起来怎么样？我确信已经有人这样做了，你的经验是什么？有什么可以改进的？我很想听听人们的意见，他们认为前端测试不仅仅是 E2E/无头浏览器和简单的单元测试。

本篇关于《有效的前端测试》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！