单元测试详解

🍅 点击文末小卡片，免费获取软件测试全套资料，资料在手，涨薪更快  

一个单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行检验。

单元测试几乎都是用单元测试框架编写的。单元测试容易编写，能快速运行。单元测试可靠、可读，并且可维护。只要产品代码不发生变化，单元测试的结果是稳定的。

单元测试应该是无需开发手动进行验证的，运行单元测试应该自动进行结果的校验并输出不通过的单元测试用例。反例是通过结果的输出手动比对。

一、单元测试是什么？

所谓单元测试，简而言之就是程序员编写测试代码来验证自己写的功能代码是否能按照要求运行。如果测试代码不能通过，就说明自己写的功能代码是有问题的。

这种自己测自己的方式似乎有些可笑，相当于考试时看着答案做题。然而在测试领域，这样的方式有个专业术语叫白盒测试。

而白盒测试的对立术语叫黑盒测试，也就是用其他方式来验证。单元测试属于白盒测试，而更高级的测试例如集成测试（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、架构师。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。