总结
要知道测试的内容，首先要知道测试的原因。下面是测试的几个主要目的：
- 避免回归
- 质量管理
- 匹配规格
- 淡化责任
- 让你放心
- 学习测试
- 选中一个框
你为什么要测试？
要决定测试什么、测试多少以及以什么顺序测试，您需要首先弄清楚测试的原因。
测试是一项艰巨的工作，需要时间、精力和资源。为了证明它的合理性，它必须服务于一个目的，你必须为每个项目定义它是什么。
目的1：避免回归
这是测试最常见的目的：确保当有人修改代码时，我们不会破坏现有的代码。这也是最帕累托和最现实的目的，因为它不需要 100% 覆盖所有边缘情况就可以给你带来良好的回报。对代码最常用的路径进行一些良好的测试将确保大多数用户在大多数时候不会生气。
大多数人都专注于单元测试，但经验告诉我，一些好的端到端测试（我们将在后面定义）可以让你走得很远。
目的2：质量管理
添加测试可能会提高软件的质量，前提是您不会过度使用并定期发布。😃
这是一个很好的副作用，但你也可以故意选择利用它来达到这个目的：
- 它将通过迫使你检查你的假设，将边缘情况摆在你面前并定期练习代码来减少代码库中的错误。
- 它将迫使你考虑你的 API，并使其可测试，从而减少耦合。
- 它会让你重新考虑你的项目范围，因为测试成本很高，所以你将不得不思考，“这个功能值得吗？
不幸的是，这引出了一个问题：什么是质量？您的质量目标是什么？你如何衡量它？
这是一个兔子洞，公司很少有客观的、可测试的质量指标清单。当他们这样做时，这些指标往往最终会被玩弄。除非你是美国宇航局，否则就顺其自然吧，特别是如果你在另一边有一个客户，他们会一路影响它。经验有很大帮助，所以如果你一开始很糟糕，不要气馁。
决定进行低级质量检查是一个完美的决定。但你必须有意识地去做。
目的3：匹配规格
测试是关于系统如何工作的实用、可读且始终保持最新状态的演示。因此，它们非常适合证明您遵循规格或标准。如果这是你的目标，你需要现在就做出决定，因为这需要纪律和整个团队的参与。在某种程度上，它比“管理质量”更容易，因为你是否匹配它更客观（尽管 IRL 实践也有办法用它来玩弄）。但这可能是一项繁琐的工作，繁琐、重复、注重细节，并且需要大量文档。
它有一个不同的、成本更低的、有点美妙的结果：它是关于代码如何工作的文档和参考。它可以帮助初学者了解您的代码库是如何滴答作响的，使入门更容易，并为您和您的 AI 插件提供参考。
即使你不符合规范，我建议你至少要牢记这个文档目标，因为它很快就会带来回报。这意味着，涵盖最常见的用例，在测试中使用好名称并执行公共 API。我甚至把一些测试做得有点太大了，这样它们读起来就像一个可执行文件，并保证是正确的教程。
目的4：淡化责任
目的5：让你放心
如果一个项目至关重要，如果人们的生活受到影响，如果你的职业生涯岌岌可危，那么看到成千上万的测试通过亮绿色支票将对你的血压产生非常积极的影响。
目的6：学习测试
目的 7：选中一个框
生活有时可能很愚蠢，是的，就像斯科特·尤雷克（Scott Jurek）在《吃就跑》中所说的那样：“有时，你只是做事。”
你的限制是什么?
你想做什么？你能做的到吗？
你需要了解你可以使用的人力，测试花费的时间，在什么条件（使用笔记本？使用特定的测试工具？什么权限？）下进行测试。
测试多少？
你应该测试多少东西？
对我来说，测试的黄金标准是SQLite代码库。他们的测试次数是代码行的 590 倍，在代码行中，他们检查诸如断电时会发生什么！但他们最近还在添加新的测试！
因此，你无法真正地全面测试！
你该测试多少取决于你希望你的项目需要什么，如果你不在乎错误，你甚至可以不进行测试，在出现问题时修复。
经验法则
如果您有产品，通过自动化 GUI 进行端到端测试是脆弱的，但也会带来最大的收益。当您没有太多时间进行测试时，您可以从此开始。与公共 Web API、cmd接口等相同。奖励：当您是初学者时，这种类型的测试更容易概念化，因为它非常具体，而且您不必解决副作用，因为您正在测试副作用。首先快速而肮脏地完成是完全可以的。但是，通过 e2e 测试，您不会获得更好的代码和架构的好处。
如果您有库，请优先测试公共 API（如果可以）。从上到下尽早锻炼你的大部分筹码，同时防止你迷失在细节中。它还将迫使您考虑程序的边界及其提供的服务，这是极客很难做到的。对一个干净的、完美的小函数进行单元测试要漂亮得多。这并不总是可行的，因为如果您从头开始启动系统，您可能需要先创建大量低级工具。
如果可靠性至关重要，并且您有一个规范，则首先按照指定测试组件，并根据其匹配的规范部分命名/注释/引用每个测试。使用类型提示，尤其是对于模型和单元。如果您必须支持规范的多个版本，则还要测试版本和命名空间。质量要求越高，就越需要通过验收测试、回溯测试、模糊测试和属性测试来补充单元测试。
纯洁往往是决定优先事项的一种糟糕方式。在项目早期，100% 的测试覆盖率很少是一个好目标，不要过分关注这一点，因为最后的百分比是昂贵的，而且带来的好处最少。这个耗资5亿欧元的项目上限为95%。混合概念和不完美也是可以的。在单元测试中可能会有一些副作用。你可能只锻炼一些分支和一些快乐的道路。您可能不会测试某些错误。测试可能介于 e2e 和单元测试之间，但两者都不完全是。不要让最好的成为好的敌人。保持你最初陈述的目标，并记住你的限制。这就是我们从他们开始的原因。它们是您的指南。
当然，现在您可能不知道什么是覆盖率、属性测试或模糊测试，这将在本系列的下一篇文章中解释。
