浅谈为什么要写单元测试
01、单元测试基本概念
在计算机编程中， 单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作，程序单元是应用的最小可测试部件 。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书要求的工作目标，没有程序错误；虽然单元测试不是什么必须的，但也不坏，这牵涉到项目管理的政策决定。每个理想的测试案例独立于其它案例；为测试时隔离模块，经常使用stubs、mock或fake等测试马甲程序。
单元测试通常由开发/测试编写，用于确保他们所写的代码符合软件需求和遵循开发目标。
02、为什么要写单元测试
我们应用编程开发技术来开发一套系统并编写单元测试，并不是为了显示和满足我开发设计能力的表现。我们要做的是 如何让系统更加的健壮，把代码问题扼杀在摇篮中，并节省每个迭代底层代码带来的测试分析和回归成本 ，所以核心是如何更好、更高效地在开发阶段就发现问题，减少重复劳动，降低回归成本，在修改代码时不用担心受怕。再者，单元测试具有较高的测试覆盖度，且是最好的文档。
03、单元测试成本
诚然，在写单元测试时需要许多额外的工作量，我们经常听到：我们项目很紧张的，我已经007了，根本不可能有时间来写单元测试；我们这个需求只是临时的，这次用完就不需要用了...;我写的代码不可能有问题的，诸如此类。确实在第一次编写单元测试时可能需要花费相比需求本身多出两倍的时间。
但软件开发中有一条重要的定律叫 规模代价平方定律，也就是定位并修复一个BUG所需的代价正比于目标代码规模的平方。
比如：
如果一个20行的函数刚写完时很快就能发现BUG，找到并修复这个BUG可能只需要1分钟；
如果是在200行的一个类中，别人调用时发现BUG，阅读代码并定位问题可能就需要一个小时，对这个问题的修复以及重新代码评审又要花一个小时；
如果在系统和系统联调的时候才发现这个问题，前面扯皮加定位问题就要半天时间，修改完成后重新验证、回归又是半天。
如果改这个BUG的人已经不是原作者的话，往往担心改了这个BUG又引入其它问题，于是修改方案就要拖一群人讨论半天，最终改完了要求QA作大范围的回归，结果还是还不放心。像支付宝体系内，有1000多个系统，可能从业务表象到定位到系统问题，可能需要找n个团队n个人一步一步沟通下去，可能导致处理慢影响到用户。
规模代价平方律是很多软件工程实践的核心思想。 根据平方律，为了减少错误修复的成本，要尽可能早的发现错误，在尽量小的范围内定位并修复错误。 由于这是一个平方律而非线性率，所有这方面的努力都是非常划算的。
综上所述，其实磨刀不误砍柴功，每个人应该对自身系统的每一行代码的质量负责，因为单元测试能够尽早在尽量小的范围内暴露错误，所以在整个项目开发过程来看，做好单元测试是能够带来降低成本、缩短工期的好处来的。
04、单元测试带来的潜在收益
测试驱动实现，促使每一行代码都可测。
接受代码多次修改，回归测试更加轻松，让应用程序长期处于稳定。
case-study行成正能量闭环。
极大减少调试时间。
促进更好的设计。
用例就是文档。
05、单元测试编写要求
给用例取一个描述性的、准确性的名字。
消除测试用例之间的重复。
测试用例彼此之间需要独立，测试用例之间不能相互依赖。
测试用例需要尽可能的简单，用例结果为简单的顺序执行，无分支、循环等控制结果。
用例能够自动判断正确与否，case fail时能够直接说明哪里的代码除了问题，无需借助debugger，不是在代码里写个System.out.println，人肉观察一下结果。
用例的结果需要强校验：对于每个方法的单元测试，需要明确判断结果的输出。
用例运行够快，一般运行时间在毫秒数量级。
用例要有覆盖度，一般对于系统变更的单测行覆盖率应达到80%，具体视各团队而定。
06、junit使用
junit是一个由Erich Gamma和Kent Beck开发的开源测试框架，可以让你进行测试所需的重要事情。以创建一个FileReaderTester类来测试文件读取器，任何包含测试代码的类（即测试用例）都必须继承测试框架所提供的TestCase类，如图所示。
07、常用的断言
断言 | 说明 |
assertEquals(expected, actual) | 查看两个对象是否相等。 |
assertNotEquals(first, second) | 查看两个对象是否不相等。 |
assertNull(object) | 查看对象是否为空 |
assertNotNull(object) | 查看对象是否不为空。 |
assertSame(expected, actual) | 测试期望值和实际值是否都引用同一个对象。 |
assertNotSame(unexpected, actual) | 测试期望值和实际值是否没有引用同一个对象。 |
assertTrue(a) | 测试a是否为 true（真）。 |
assertFalse(a) | 测试a是否为 false（假）。 |
08、junit常用元数据
元数据 | 说明 |
@Before | 使用了该元数据的方法在每个测试方法执行之前都要执行一次。 |
@After | 使用了该元数据的方法在每个测试方法执行之后要执行一次。 |
@Test | 测试方法，在这里可以测试期望异常和超时时间。 |
09、谁来写单元测试
谁来写单元测试一直是一个值得争论的问题，原因一般在于工期排期，下面简要分析开发和测试在写单测过程中面临的问题，及如何更好得配合来提升单测覆盖率及效率。
开发写单测
开发扎根系统深度，对自己写的代码最熟悉，开发写单元测试比较顺手效率比较高，每个开发都应该对自己编写的代码负责。但开发说我平时写业务代码就忙不过来了，哪有时间写单元测试？而且大部分开发并没有很好的测试思想，单元测试可能只是写个最简单的用例就完了，最终可能单元测试通过，但基本的功能还是有问题，这样的单测没有太大作用。
测试写单测
测试对系统间的广度有较好的把握，有比较好的测试思想，可以更好地保证用例的校验点和覆盖度。通过写单测测试能更好地了解具体代码结构、流程，对于后续的业务测试也有利。但测试也有很多需求要测试，测试对具体代码实现细节没有开发熟悉，遇上为了可测性需要重构的时候还是得开发花时间配合，效率上不如开发自己写。
对于类似场景，我认为 测试可以把测试思想赋能给开发，做到测试驱动开发。 TDD带来的最大好处是 提高了单元测试的覆盖率。
因为每一种语言都离不开条件分支、循环处理和函数调用等最基本的逻辑控制，我们抛开代码需要实现的具体业务逻辑，仅看代码结构的话，实际上所有的代码都是在对数据进行分类处理，每一次条件的判定都是一次分类处理，嵌套的条件判定或者循环执行，也是在做分类处理。如果有任何一个分类遗漏，都会产生缺陷；如果有任何一个分类错误，也会产生缺陷；如果分类正确也没有遗漏，但是分类时的处理逻辑错误，也同样会产生缺陷。
可见， 要做到代码功能逻辑正确，必须做到 分类正确并且完备无遗漏 ， 同时每个分类的处理逻辑必须正确。
在具体的工程实践中，测试可以赋能开发 等价类划分 的能力，让开发把等价类运用到单元测试中， 测试同学在每次代码提交时详细CR开发提交的每一个单测用例。
如果要实现正确的功能逻辑，会有哪几种正常的输入；
是否有需要特殊处理的多种边界输入；
各种潜在非法输入的可能性以及如何处理。
最后，在初期时开发和测试都可以借助linke平台去分析未覆盖到的分支。
10、参考文档&推荐阅读
1.《程序员的职业素养》 http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
2.《重构》
3.《测试驱动开发》
来源：蚂蚁研发效能
本文内容仅供个人学习/研究/参考使用，不构成任何决策建议或专业指导。分享/转载时请标明原文来源，同时请勿将内容用于商业售卖、虚假宣传等非学习用途哦～感谢您的理解与支持！
