前端测试原理

前端测试原理

编写前端测试可能非常困难。你有很多事情要考虑，要做出的选择，以及你可以走的路。在本文中，我们将探讨编写更好测试的 5 个原则，让您有充分的信心将新功能推向生产环境。

在开始之前，重要的是要提到这篇文章是：

• 专注于 前端测试 特别是（即 React 应用程序及其与组件的交互）。
• 高度基于所写内容 肯特·C·多兹 ，他是 React 社区的著名开发者 ( https://kentcdodds.com/ ）。

一）简介

在之前的文章中，我们回答了“我们为什么要编写测试？”这个问题。并定义了一个测试策略：“测试奖杯”。

[

前端测试策略

定义常见的测试层及其权衡，以提出有效的策略。

itnext.io

](/front-end-testing-strategy-5fddfd463feb)

现在是时候看看与该哲学完美匹配的 5 项原则了。

二）原则

1. 以与用户使用软件相同的方式测试您的软件

我们希望编写可维护的测试，让您高度确信您的组件正在为您的用户工作。
对于前端，我们只需要关注两个测试目标：

• 这 最终用户 谁在浏览器中与您的组件交互。
• 这 开发商 谁在代码中呈现和使用您的组件。

只要您的测试服务于这两个，那么它们就有存在的理由。

但是我们经常引入第三个用户， 测试用户。 该用户 **** 通常测试我们的消费者和我们的业务都不关心的东西（例如：测试实现细节）。
但是通过以这种方式进行测试，您只会对以下用户充满信心：

• 不支付账单像 最终用户 .
• 不会像 开发者用户 .

此外，您现在必须牢记第三个用户，并确保您考虑了影响测试用户的更改。

资源： Kent C. Dodds — 避开测试用户

2.避免测试实现细节

这 测试用户 倾向于测试所谓的“实施细节”。

实施细节可能导致：

• 误报：重构应用程序代码时可能会中断。
• 误报：当我们破坏应用程序代码时可能不会失败。

这就是为什么在大多数情况下 我们想避免它们 ，这将使我们的测试：

• 更接近我们的用户（最终用户和开发人员）如何使用我们的组件。这让我们确信我们的应用程序正在按预期工作。
• 更有弹性。组件的重构不会破坏我们的测试，因此不会减慢我们的团队和我们的速度。

您的测试应该更加关注您的用户可以满足的实际用例。

**如何确定实现细节？
** — 如果我们的测试做了我们代码的使用者没有做的事情，那么它就是在测试实现细节。 （通过示例公开私有函数）。
— 如果内部重构（对实现的更改但不是功能的更改）破坏了您的测试，那么它正在测试实现细节

**“实施细节”示例：
** — 组件的内部状态
— 组件的内部方法
— 组件的生命周期方法
— 子组件

重要的是要注意，仍有一些情况需要测试实现细节。在 React 中，我们可以考虑一个自定义的钩子，它有很多内部逻辑，并且可以在你的应用程序中共享。

但这些应该是稀有且精心挑选的。

资源： Kent C. Dodds — 避免实现细节

3. 编写更少、更长的测试

许多人阅读组件的需求列表并将其转换为单独的测试用例。也许您已经阅读过所谓的“每个测试最佳实践只有一个断言”。
但是最初创建该规则是因为测试框架在为您提供确定导致测试失败的原因所需的上下文信息方面做得很差。

如今，多亏了我们惊人的工具，识别导致失败的断言是微不足道的。如果您想让事情更清楚，您可以在断言上方添加代码注释，以解释您所做的断言的重要性。

不用担心进行长时间的测试。当您考虑您的两个用户并避免 测试用户 ，那么您的测试通常会涉及多个操作和断言，这是一件好事。不要随意地将您的断言分成单独的测试块，这样做没有充分的理由。

**如何确定你的测试？
** 为手动测试人员考虑一个测试用例工作流程，并尝试让您的每个测试用例都包含该工作流程的所有部分。

资源： Kent C. Dodds — 编写更少的较长测试

3. 编写测试时要考虑到易于理解和可维护性

这 AHA 编程原理 代表“避免仓促抽象”。它说当你开始编写抽象时，你不应该教条主义，而是在感觉正确的时候编写抽象，并且不要害怕重复代码，直到你到达那里。

在抽象范围的中间找到一个最佳位置是开发可维护代码的关键。

该原则完全可以应用于编写可维护的测试。提醒一下，您编写测试以确信您今天在生产中推送的代码在以后发生更改的情况下不会中断。但是测试也应该是您或任何其他可能在未来返回它的开发人员的帮助，以便轻松了解测试组件的目的（在功能和关键特性方面）是什么。这样，你想 让您的测试易于理解且高度可维护 .

资源： Kent C. Dodds — AHA 测试

4. 单独编写测试

隔离测试意味着运行一个测试的副作用不应影响其他测试的结果。我们应该能够以任何顺序独立执行它们，而不会改变获得的结果。

隔离测试是一般测试的一个重要原则，因为当它没有得到很好的尊重时，它是导致片状测试（每次运行它时都无法产生相同结果的测试）的最主要原因之一。

由于测试应该是独立的并且它们的执行顺序无关紧要，Jest 可以并行运行它们，这大大提高了总执行时间。

单独编写测试将引导我们以更好的方式编写测试，以提高其可靠性、简化代码并增加信心。

资源： Kent C. Dodds — 测试隔离

5. 小心模拟

模拟被认为是权宜之计，它允许我们测试某些难以或懒惰测试的东西（例如：测试信用卡服务，我们不想玩生产的数据和服务等真钱）。

请记住， 当我们嘲笑某些东西时，我们是在进行权衡 .我们通常用信心换取实用性。即使我们确信我们的代码可以与我们的假服务版本一起使用，我们也不能 100% 确信我们的代码可以在生产环境中与真实版本一起使用。

肯定有一些地方可以模拟（特别是当我们谈论不同级别的测试时），但我们需要意识到我们做出了权衡。

资源： Kent C. Dodds — 测试模拟

三）结论

正如我所说，前端测试具有挑战性。要编写相关测试，您必须将自己从自己的开发人员思维模式中分离出来，而是尝试像真正的用户一样思考，将 UI 视为一个整体。由于其他开发人员会在您之后添加自己的代码和测试，因此您还需要非常注意可维护性和可理解性。

请记住，编写测试的主要目的是增加您对应用程序的信心。您希望确保实现的功能在今天按预期工作，并且在未来不会中断。为了编写测试（或匹配任意最小代码覆盖率）而编写测试没有任何价值，而且通常会浪费时间和金钱。
我希望这些原则能帮助你完成这个旅程。

感谢您的阅读。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/33180/38301308