单元测试真的毫无用处吗？💩😳

我一直认为单元测试是工作的一部分。它们就在那里，对添加到代码库中的每一段新代码进行测试是理所当然的。

直到最近，我偶然遇到一位领导工程团队的人，他采取了一种截然不同的方法。他们拒绝为整个生产应用程序编写哪怕一个自动化测试。

你可能会说：“嗯，这家伙只是在和他的10个用户玩玩而已。”

但当我深入研究讨论后发现，Facebook、Twitch 和 Netflix 的一些团队也采用了类似的策略。

所以这到底是怎么回事？难道我们从此以后都应该停止单元测试吗？

✅ 单元测试的预期好处

你或许还能找到更多好处，但这些好处被反复提及：

单元测试可以帮助您：

• 在将代码部署到生产环境之前尽早发现并修复漏洞。
• 当你的代码发生更改时，能够捕获错误。
• 改进你的代码设计，
• 记录你的系统是如何工作的。

假设你编写的单元测试不是垃圾，那么这些好处都是合理的。但它们也是有代价的。

💰 单元测试的成本

单元测试的设置和维护成本都很高。

问题不在于单元测试是否有益处，而在于这些益处是否值得付出。

开发人员需要不断思考如何以有意义的方式设计测试，如何模拟事物，如何提高代码覆盖率，以及是否涵盖了所有潜在的边界情况。

此外，当部分代码发生更改时，无论最初的测试设计得多么出色，他们可能都不得不重构数十个测试。

所有这些都可能导致工程师们变得非常不愿意修改那些因过多的单元测试而固定下来的现有代码。他们往往避免重新思考现有的解决方案，尝试新事物，以及在总体上保持大胆创新的态度。

🦧 你可以做些什么来代替？

1. 使用强大的工具
集 强大的工具集可以提前发现很多问题。代码审查、代码检查工具、严格的类型检查以及一些完善的编码规范，都能为打造健壮的产品奠定良好的基础。

2. 手动测试
如果确实需要测试某些内容，请手动测试。没错，你会重复劳动，但这样更接近生产环境，也更容易测试那些可能无法自动测试的场景。

3. 依靠用户发现 bug 而不是工程师猜测
。你可能已经解决了显而易见的问题。但你遇到的绝大多数 bug 都来自你做梦都想不到的极端情况。如果你接受代码在生产环境中不可避免地会出错，你的关注点就会更多地转移到如何快速修复问题上。

4. 添加安全机制
说到快速修复，重点在于创建安全机制，以便尽快检测和解决错误。这些机制包括逐步推出新功能、使用优秀的错误和性能监控工具，以及设置功能开关，以便在出现任何问题时快速回滚。

5. 记录下来
如果遇到奇怪的极端情况，在代码中快速添加注释，解释代码存在的原因，并与团队成员讨论。这样，在重构代码时，你就能记住所有内容。

6. 代码编写的目的是为了重写。
在团队中要明确这一点。你永远不可能第一次就写出完美的代码。鼓励频繁改进，不要让任何人害怕修改别人的代码。

7. 专注于代码本身，而不是支撑结构。
如果你的代码很脆弱，当你添加或修改其中的部分时，它就会不断崩溃，那么你应该把精力集中在使代码更加健壮上，而不是使围绕它的测试更加复杂。

🤔 所以，你应该放弃考试吗？

有些情况下，一次故障的代价是完全无法接受的。例如银行业或关键基础设施。这些系统必须始终保持100%的正常运行，任何差错都得不偿失。

此外，对于规模较大的公司来说，单元测试绝对是值得的。尤其是在涉及人员过多且系统频繁出现故障的情况下。

但这一点出现得比你想象的要晚。Netflix 显然在没有完善的测试套件的情况下就达到了 1 亿用户（一位前 Netflix 工程师谈到单元测试时说道）。

因此，如果您是一家初创公司或中型企业，并且您的首要任务是快速发展，那么您或许可以比想象中更长时间地无需进行单元测试。甚至更进一步，这或许对您的公司更有利，因为您可以专注于建立流程，从而更快地修复错误。

你对单元测试有什么看法？

编辑：
不使用自动化测试并不是随意编写代码的借口。这就像驾驶跑车进入竞速模式以求快速前进，但你最好清楚自己在做什么。这要求你时刻保持警惕，并且能够坦然面对过程中可能遇到的各种问题。

附注：

如果您想深入了解，请观看这​​段关于此话题的精彩讨论：
https://www.youtube.com/watch?v =pvBHyip4peo