Long Live the Test Pyramid
最近看到一篇关于测试金字塔的讨论，觉得非常有道理，原文在这里: https://www.smashingmagazine.com/2023/09/long-live-test-pyramid/
顺便翻译一下，希望对大家有所帮助。
我亲爱的同事 Jan Philip Pietrczyk 曾经对开发者在编写功能代码方面的责任发表过评论：
“我们的日常工作最终会交到信任我们的人手中，他们不仅信任我们已经尽力而为，还信任我们的代码能够正常运行。” — Jan Philip Pietrczyk
他的这些话一直深深地印在了我的脑海中，因为它让我们的代码置于依赖它的人们的背景之中。在这个快节奏的世界里，用户信任我们编写最优秀的代码，并且我们的软件“简单地”可以运行。确实，要达到这种信任水平是一个挑战，这就是为什么测试是任何开发堆栈中如此重要的一部分。测试过程评估了我们工作的质量，通过对不同情况进行验证，帮助在问题变得严重之前识别问题。
测试金字塔是众多测试策略之一。尽管自 2012 年引入以来，它可能已经成为了主要的测试模型，在过去的十年中占据主导地位，但我发现现在提及它的次数并不像过去那么多。它是否仍然是测试的“首选”方法？与此同时，许多其他方法也已经涌现，因此是否可能是测试金字塔被更适合当今开发的更现代模型所淹没和遮盖？
这就是我想要探讨的问题。
测试策略的关键点
与用户建立信任需要一个强大的测试策略，以确保我们编写的代码使产品按照他们的期望工作。我们应该从哪里开始编写好的测试？我们需要多少个测试？许多人一直在思考这个问题。但是 Kent C. Dodds 发表的一个简短评论让我恍然大悟。
“最大的挑战是知道要测试什么，以及如何进行测试，以获得真正的信心，而不是测试实现细节所带来的虚假信心。”
-Kent C. Dodds 这就是起点！确定测试的目标是测试策略中最关键的任务。互联网上充斥着描绘糟糕决策的迷因，其中许多是因为根本不知道特定测试的目的以及我们需要多少测试来确保信心。在测试方面，有一个“正确的比例”，以确保代码经过适当的测试并且按照预期工作。
问题在于许多开发人员只关注一种类型的测试 - 通常是单元测试覆盖率 - 而不是对各种单元如何协同工作制定策略。例如，当测试一个水槽时，我们可以分别测试水龙头和下水道，但它们是否协同工作呢？如果下水道堵塞，而水龙头继续放水，那么事情就不正常了，即使单元测试表明水龙头正常工作。
关于测试的方法通常用不同的形状来描述，就像我们已经看到金字塔模型一样。在这篇文章中，我想分享一些我观察到的形状，以及它们在现实场景中的应用，最后总结出哪种测试策略符合我对当今开发实践中良好测试覆盖的个人标准。
回顾基础知识
在此之前，让我们回顾一些不同测试类型的常见定义，以刷新我们的记忆：
手动测试
这是由实际人员执行的测试。这意味着测试将要求真实用户按照脚本化的使用案例进行点击应用程序，以及未经脚本化的尝试在不可预见的情况下“破坏”应用程序。这通常是通过与由产品团队观察的用户进行面对面或远程面试来完成的。
单元测试
这种类型的测试是将应用程序分解为小的、隔离的、可测试的部分，或者称为“单元”，通过分别和独立地测试每个单元以确保其正常运行来提供覆盖。
集成测试
这些测试关注组件或系统之间的交互。它们一起观察单元测试，以检查它们在集成在一起作为整体工作时是否良好。
端到端（E2E）测试
在这种类型的测试中，计算机模拟实际用户的交互。将 E2E 视为验证用户故事的一种方式：用户是否可以完成需要一系列步骤的特定任务，结果是否符合预期？这是从用户体验的一端到另一端进行测试，确保输入产生正确的输出。
那么，这些测试类型应该如何互相交互呢？测试金字塔是我们传统依赖的隐喻，用来将这些不同类型的测试整合到一个完整的测试套件中，适用于任何应用程序。
伟大的测试金字塔
测试金字塔是由 Mike Cohn 在他的书《成功的敏捷》中首次引入，并由 Martin Fowler 在他的“实用测试金字塔”文章中进一步发展的，根据测试的性能和成本对测试进行了优先排序。它建议编写具有不同粒度级别的测试，包括较少的高级别测试以及更多快速、经济、可靠的单元测试。推荐的测试顺序是从快速和经济到慢和昂贵，从底部开始有很多单元测试，然后是服务，即中间的集成测试。然后是位于顶部的较少但更具体的 UI 测试，包括端到端测试。
