根据 Bob 大叔的说法，测试是系统的一部分；许多开发人员认为相反，因为他们没有部署。他宣称这是一个灾难性的观点，因为测试的作用是支持开发并保持系统的健壮性和易于更改。

在前端，通常会测试最终用户与我们应用程序的交互。我们应该向用户保证，当他们登录、打开弹出窗口、添加评论或与我们的应用程序进行任何其他交互时，不会遇到任何错误和不愉快的体验。

在前端进行测试，如果正确完成，将使我们的用户感到满意，并在使用我们的应用程序时获得良好的性能体验。另一方面，对于开发者来说，会节省大量的时间去解决bug，或者在添加新特性的时候，不会破坏代码之前的行为。

为什么测试会不利？如何设计测试系统？

测试需要时间，也需要与开发过程中的变化保持一致。此外，随着设备和浏览器的发展，我们需要与时俱进。在软件测试中，有一个称为脆弱测试问题的概念。这可以定义为导致数百个测试失败的系统中的一个更改。Bob 大叔强调了设计良好的测试系统对于我们系统的稳定性和回归的预期好处的重要性（Clean Architecture，Robert C. Martin，2018）。

我们将描述一些可能有助于我们测试系统设计的方法和策略：

Martin Fowler 在他的文章“关于测试的多样化和奇异的形式”中讲述了当他们向测试专家询问单元测试的定义时他的那一刻。他说，这位专家的回答是，他在培训课程的第一天早上就涵盖了 24 种不同的单元测试定义。由于单元测试有许多不同的定义，在本文中，我们将包括 Fowler 称为单独测试的一种。

在著名的测试金字塔中，在底部，我们遇到了测试覆盖率较低但执行速度最快的单元测试。在第二层，我们看到了集成测试，它的覆盖率更高，但速度较慢，因为它可能会连接到外部部件。最后，我们有 E2E 测试或一些呼叫验收测试，它们覆盖了应用程序的很大一部分，但它们执行起来最慢。

单元测试单独检查我们的组件是否正常工作。它们还涵盖了要测试的边缘案例，这使我们的代码库更加可靠。单元测试之后是集成测试的实施。集成测试检查相互连接时独立开发的两个软件单元或模块之间的通信。他们分析系统连接时的行为，并检查微服务之间的交互。它们还包括 API 连接，这就是为什么它们在单元测试方面速度较慢的原因，因为连接可能会延迟，或者服务可能会关闭。在前端，集成测试用于检查返回 API 的数据是否具有正确的对象、数组或格式。

E2E 测试模拟用户行为并检查用户与我们应用程序的所有交互。它们是在真实浏览器中执行的集成测试的专门版本。它们通常在合并或发布之前运行，因为完成测试的执行可能需要数小时。

在下文中，我们还提到了测试技术，例如 Accessibility 和 UI：

可访问性测试检查用户界面是否可供每个用户轻松使用，并使我们的应用程序可用于残障人士。Jest-axe 是一个很棒的 Jest 测试库，它允许我们检查应用程序的可访问性。

UI 测试检查我们应用程序的用户界面是否正常工作。如果用户输入内容、单击复选框或删除元素，应该可以正常工作并按预期更新 UI 状态。

一些前端测试库回顾

Jest 是一个主要用于前端单元和集成测试的库。由于其巧妙的并行测试机制实现，对于测试文件较多的大型项目来说速度非常快。

测试库是一个我们可以编写单元和集成测试的库。它有助于方便的选择器、触发事件、配置、处理异步代码等等。

Cypress 是一个将其测试注入 Cypress.io 在浏览器中自行运行的网站的库。我们可以高效地编写单元、集成和端到端测试。

它为开发者提供了更快的体验，我们可以很容易地在它的浏览器上看到错误。

Applitools 用于视觉回归测试。凭借其先进的 AI 技术，它可以检测图像和 DOM 之间的差异。检查我们网站的外观是否与前一个相同或是否发生错误非常有用。此外，如果用户在移动设备或网络上可以正确看到网站上的任何项目或按钮，它还会检查不同的浏览器和平台。

结论

前端测试应该是我们开发的一部分，以便在代码投入生产之前解决代码中的问题。我们应该编写单元测试来检查我们应用程序中的每个功能，还应该开发集成测试来检查所有组件和模块是否一起正常工作。另一方面，我们应该编写 E2E 测试来自动化手动点击测试，并以用户与我们的应用程序交互的方式为中心。

我们应该编写测试来提供信心，而不仅仅是改进指标。正如 Robert C. Martin 所说，我们应该避免编写与系统强耦合的测试。因为即使是最微不足道的更改也会导致许多测试中断。