测试的重要性

测试与质量保证总体上被低估，常常被推迟，且未得到应有的重视。你可能听过类似以下的说法：

• "我们没时间写测试！下一个版本必须发布，以确保我们达成里程碑。"
• "让我们尽快发布这个新功能，稍后再写测试。"
• "我们每 n 个迭代专门用于编写测试。"

对于上述每种说法，都有些你需要注意的“小秘密”。

"我们没时间写测试！下一个版本必须发布，以确保我们达成里程碑。"

编写测试需要成为规划过程的一部分，并融入团队所做的一切工作中。如果负责路线图的人不重视测试，产品从一开始就极有可能注定失败。这种问题不会立即显现，甚至可能在第一、第二年都不会出现，但一旦团队规模扩大或成员离开，开发速度将迅速停滞，每次发布时回归错误的可能性都会增加。

"让我们尽快发布这个新功能，稍后再写测试。"

“稍后”永远不会到来，因为下一个版本的重要性总是超过为之前发布的功能编写测试。

"我们每 n 个迭代专门用于编写测试。"

你不会这么做。这是缺乏经验的产品经理用来贬低测试重要性的一种策略。即使你真的每 n 个迭代都写测试，也已经太迟了，因为某些功能可能已经在几个迭代中出现问题。此外，为 n 个迭代前开发并发布的功能编写测试，效率和全面性远不如在开发过程中，甚至在编写功能之前（如 测试驱动开发 (TDD) 所倡导的那样）进行测试。

在我们深入本课程将采用的具体方法之前，我们需要清楚地理解并行测试的重要性：

不编写、维护和监控应用程序的自动化测试套件，就像人类不睡觉一样。短期内一切正常，但从长远来看，事情将以意想不到的方式崩溃。

还有一个概念你应该了解，即 测试金字塔。它由 Mike Cohn 在其著作《Succeeding with Agile》中提出。

测试金字塔

Cypress 出现之前

测试金字塔建议编写大量单元测试，较少的系统测试，以及更少的端到端测试。

这一理念背后的逻辑是：单元测试体积小，开发成本低，执行速度快。金字塔顶端是端到端测试。理论上应只编写少量，因为它们开发、执行和维护耗时较长。事实上，这在过去确实如此，因为端到端测试框架难以应对网页应用的实际表现。由于网络特性，页面大多数时间可能在一秒钟内加载，但有时会因网络问题、数据库响应缓慢等原因，耗时长达三倍。在这种情况下，端到端测试经常失败或行为不可靠，导致不必要的排查工作。

这一金字塔及其理念一直是标准建议，直到开发者了解到 Cypress。

Cypress 出现之后

下图展示了当前对测试金字塔的理解。

如今，端到端测试不再像过去那样脆弱。得益于测试运行的并行执行，它们的执行速度显著提升。最重要的是，单个端到端测试覆盖的范围更大，因此更有可能发现更多缺陷。相比之下，单个单元测试仅关注一个函数，通常依赖项会被模拟。模拟的依赖项并不能反映生产环境中的真实情况，可能导致误报。

在本课程中，我们将选择 Cypress 作为测试工具。我们希望你能体会到编写端到端测试可以是一种真正的乐趣！

编写测试的建议

在某些环境中，人们曾提倡 100% 的单元测试覆盖率。如今，这种做法已不再被认为明智，反而会给团队带来痛苦和不确定性。我们将从这些错误中吸取教训，遵循更好的实践。单元测试当然有价值，但基于单元测试追求 100% 代码覆盖率并不值得投入那么多精力。

应重点关注自动化端到端（UI）测试，以及对最复杂功能单元编写少量单元测试。此外，应注重编写有意义的测试，而不是为了达到高单元测试覆盖率而盲目编写测试。测试最重要的价值在于发现用户体验方面的问题。如果我们为所有用户旅程编写端到端测试，并且所有测试都通过，那么我们可以确信系统按预期工作。

然而，你可能会问：“那故障场景呢？如何编写测试用例来确保当后端无法连接数据库时，错误能被妥善处理？” 在这种情况下，一组底层的集成测试和单元测试是有用的。以 Firestore 为例，客户端与数据库之间没有中间后端，这个问题相对较小，但在存在后端层或 API 的情况下，这一点绝对至关重要。

我们代码库中可能有 20 个函数从未被调用过。无论是因为它们是遗留代码不再使用，忘记调用，还是被功能开关隐藏，都不重要。如果它们未被用于覆盖所有用户旅程，就不需要测试。不过，总有一天，它们需要被清理！

在接下来的课程中，让我们看看让 Web 应用测试变得愉快的两个关键要素：Cypress 和 Testing Library。

针对你的 Web 应用的测试

我们将重点关注两个主要领域：端到端测试 和 组件测试。在本章末尾，我们将把测试集成到持续集成流水线中，并将测试结果报告到 Cypress Dashboard。

首先，请参考我们的 项目概览 图表，明确本章我们将聚焦于架构的哪些部分：