作为从事软件开发多年的资深码农，看遍了各种事故和火葬现场。在接触测试驱动开发以及敏捷之后，发现这正是解决 bug 丛生、issue 漫天，最终导致 996 、007 修 bug 的困境。
这里将单元测试的一些看法分享给大家，希望能够提供一些启发。英译版同步发布在 dev.to，欢迎一起交流学习。
下面是正文。
"开发安全可靠的应用程序的最好方式，就是不写代码。"--Kelsey Hightower
很多开发者应该或多或少听过单元测试（ Unit Tests ），甚至编写过，也或许对其有所了解。不过，在如今瞬息万变的环境下，单元测试似乎正在成为鸡肋。程序员们都知道它的好处，但是对其显得比较冷淡。“进度这么赶，还有什么时间写单元测试呢？”这样的话是不是听着很熟悉？
所谓单元测试，简而言之就是程序员编写测试代码来验证自己写的功能代码是否能按照要求运行。如果测试代码不能通过，就说明自己写的功能代码是有问题的。
这种自己测自己的方式似乎有些可笑，相当于考试时看着答案做题。然而在测试领域，这样的方式有个专业术语叫白盒测试。而白盒测试的对立术语叫黑盒测试，也就是用其他方式来验证。单元测试属于白盒测试，而更高级的测试例如集成测试（ Integration Tests ）、端到端测试（ End to End Tests ）、UI 测试（ UI Tests ），都属于黑盒测试。单元测试仅仅是测试代码本身。
单元测试在敏捷开发（ Agile Development ）中是非常有用的工具。甚至有些敏捷框架，例如极限编程（ XP ），就要求每一个功能必须被单元测试覆盖。在之前的文章《浅谈敏捷：你的团队在正确实践敏捷吗？》就提到过单元测试的重要性。
概括来说，单元测试有下面几个重要作用：
因此，表面上来看，单元测试对于软件开发来说会带来比较大的收益。
单元测试可以提高我们的产品质量、测试效率，那为什么程序员还是不喜欢写单元测试呢？据 JetBrains 统计，被调查者中仅有 57% 要写单元测试，仅有 35% 会在大部分项目中实施自动化测试。
那么，为什么？有几个可能的主要原因：
然而，这几个原因都经不起推敲：第一，长期来看自己修复 bug 写的代码量肯定远不止这么点；第二，不管是多么牛逼的程序员，代码写多了，根据大数定理，都会有失误的时候；第三，简单功能如果被引用多了，也会变得重要；第四，QA 的主要工作是保证整体质量，而单元测试是保证局部质量，缺陷部件组装出的产品会优质么？
其实，这里最主要的原因是思维模式，程序员大部分时候会站在个体的角度，思考短期的问题，从而忽略了长期的成本收益。作为一个合格的开发者，最主要目标是用最有效的方式开发出最大价值的功能。因此，单元测试在短时间内无法创造价值，从而被很多人忽视。
单元测试就像读书，短期内不能让人知识渊博、名利兼收，但长期来看是会有效果的。单元测试如果成为习惯或组织文化，就会更容易打造高质量产品和持续交付。要在团队中推广单元测试，需要更根本的流程，例如极限编程、测试驱动编程，或者更高决策者，例如 CTO 、架构师。
如果您对笔者的文章感兴趣，可以加笔者微信 tikazyq1 并注明 "码之道"，笔者会将你拉入 "码之道" 交流群。
本篇文章英文版同步发布在 dev.to，技术分享无国界，欢迎大佬们指点。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.