引子
"开发安全可靠的应用程序的最好方式，就是不写代码。"--Kelsey Hightower
很多开发者应该或多或少听过单元测试（Unit Tests），甚至编写过，也或许对其有所了解。不过，在如今瞬息万变的环境下，单元测试似乎正在成为鸡肋。程序员们都知道它的好处，但是对其显得比较冷淡。“进度这么赶，还有什么时间写单元测试呢？”这样的话是不是听着很熟悉？
单元测试是什么？
所谓单元测试，简而言之就是程序员编写测试代码来验证自己写的功能代码是否能按照要求运行。如果测试代码不能通过，就说明自己写的功能代码是有问题的。
这种自己测自己的方式似乎有些可笑，相当于考试时看着答案做题。然而在测试领域，这样的方式有个专业术语叫白盒测试。而白盒测试的对立术语叫黑盒测试，也就是用其他方式来验证。单元测试属于白盒测试，而更高级的测试例如集成测试（Integration Tests）、端到端测试（End to End Tests）、UI 测试（UI Tests），都属于黑盒测试。单元测试仅仅是测试代码本身。
单元测试有什么用？
单元测试在敏捷开发（Agile Development）中是非常有用的工具。甚至有些敏捷框架，例如极限编程（XP），就要求每一个功能必须被单元测试覆盖。在之前的文章《浅谈敏捷：你的团队在正确实践敏捷吗？》就提到过单元测试的重要性。
概括来说，单元测试有下面几个重要作用：
可持续质量保证：单元测试能保证业务逻辑代码在经常性的被更改或重构之后不被破坏
自动化集成：单元测试一般可以集成到 CI/CD 中，当代码提交后自动触发
功能文档化：测试用例可以帮助新接触该代码的开发者熟悉代码的功能和验证条件
因此，表面上来看，单元测试对于软件开发来说会带来比较大的收益。
为什么不写单元测试？
单元测试可以提高我们的产品质量、测试效率，那为什么程序员还是不喜欢写单元测试呢？据 JetBrains 统计，被调查者中仅有 57% 要写单元测试，仅有 35% 会在大部分项目中实施自动化测试。
那么，为什么？有几个可能的主要原因：
工作量变多：“50 行代码的功能，要我写 100 行来测？不加班能完成？”
专业自信：“我一个资深程序员，写出来的程序怎么可能有 bug 呢？”
感觉不适用：“就这么几个页面，也需要写单元测试？”
有专人测试：“反正都有QA了，找他们来不就是找 bug 么？”
然而，这几个原因都经不起推敲：第一，长期来看自己修复 bug 写的代码量肯定远不止这么点；第二，不管是多么牛逼的程序员，代码写多了，根据大数定理，都会有失误的时候；第三，简单功能如果被引用多了，也会变得重要；第四，QA 的主要工作是保证整体质量，而单元测试是保证局部质量，缺陷部件组装出的产品会优质么？
变得有远见
其实，这里最主要的原因是思维模式，程序员大部分时候会站在个体的角度，思考短期的问题，从而忽略了长期的成本收益。作为一个合格的开发者，最主要目标是用最有效的方式开发出最大价值的功能。因此，单元测试在短时间内无法创造价值，从而被很多人忽视。
单元测试就像读书，短期内不能让人知识渊博、名利兼收，但长期来看是会有效果的。单元测试如果成为习惯或组织文化，就会更容易打造高质量产品和持续交付。要在团队中推广单元测试，需要更根本的流程，例如极限编程、测试驱动编程，或者更高决策者，例如 CTO、架构师。
