前言
近期在回顾一些测试的概念，其中有个测试金字塔的概念来自于 Mike Cohn 的书《Succeeding with Agile: Software Development Using Scrum》。还没有看过这本书，但这个词汇只要有研究过测试多少都会接触到，这次来重新了解一下并输出自己对这个议题的理解。
测试有三种
- 单元测试：测试程序代码最小功能单元的测试，如无依赖单一函数。
- 整合测试：测试模块之间是否运作正确，如 DB 和后端服务。
- 端到端测试：测试用户实际操作流程。
单元测试验证单一组件，整合测试检查组件交互，端到端测试验证整个系统。
测试要像金字塔
测试金字塔是一种概念关于测试理想上的最优分布，强调从成本考量来看，通过大量能够快速执行、撰写、独立的单元测试作为基底，随着测试范围的提升成本也逐步升高，测试也会更为脆弱难以维持。范围更广的测试会因为任何一丁点错误而失败，所以让我们在问题的初期小范围测试就快速抓出问题。
我体会的真实世界测试
有用的程序都是挣扎试错过来的，现实世界需求不确定的情况下测试只会是绊脚石，所以大概也只有存活下来的程序才有需求去维护测试。最可能遇到的情境是程序趋向稳定但从来没有自动化测试甚至文档，对代码的信心度极低且有点改不动的状况，遇到太多改 A 坏 B 或测试的负担过大才会开始考虑测试。
要根据金字塔模型从单元测试开始补齐吗？好像没有必要…… 一是一时半会补不完，二是不符合效益，很多逻辑都是一次性且充满取舍的。
反而这时候是最脆弱最难维护的 E2E 测试比较帮得上忙，因为它是黑箱测试（不需要知道内部程序逻辑），可以补上期望的行为即可，一次测试大量功能并提供程序能运作的信心。
测试金字塔是很好也有道理的的概念，但实际情境中没有这么美好。
世界在改变测试也是
测试的工具与环境还在持续演进，也有不同的概念可以解决问题，像是为什么测试会是「慢」的？为什么它会被视为「绊脚石」？
- 在 TDD 的概念中，要求测试（自动化文件）要先定义清楚才能写下代码，测试角色不一定是挡路的护栏而是指标，防止走错路。
- 在 AI 有清晰上下文的协助下，测试是弹指就能补足的事。
- 测试工具和硬件的增强，测试可以执行得更快更即时。