写好单元测试
What
单元测试，是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。
总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在像C++,Java这样的面向对象的语言中， 要进行测试的基本单元是类。但一般都是测试到方法.(包括重要的私有方法)
经常与单元测试联系起来的另外一些开发活动包括代码审查（Code review)，静态分析（Static analysis)和动态分析（Dynamic analysis)(DEBUG 工具)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
其实我们每天都在做单元测试。你写了一个函数，总是要执行一下，看看功能是否正常，这，也是单元测试，这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。
When
什么时候测试？单元测试越早越好，早到什么程度？TDD要求先编写测试代码，再进行开发。按照测试拟定的测试用例进行开发.
Who
由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。
单元测试应避免编写桩代码.
桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。
Why
成本效率
很多研究成果表明，无论什么时候作出修改都需要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量都得到最好的保证。Bug发现的越晚，修改它所需的费用就越高，因此从经济角度来看， 应该尽可能早的查找和修改Bug。
它是一种验证行为。
程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支援。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。
它是一种设计行为。
编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。
它是一种编写文档的行为。
单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。
它具有回归性。
自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。
How
对于经验丰富的人,他们通常都能够洞察出系统哪些方面最可能出现问题,然后集中地对这些方面进行测试;但是如果不具备那么多经验的话,要想发现这些可能出问题的bug,将会相当困难且令人沮丧.但是另一方面,最终的用户通常能够发现我们的bug,让我们非常难堪,这同时给职业升迁带来极大的不利.
Right-BICEP
- Right----结果是否正确
- B----是否所有的边界条件都是正确的
- I----能查一下反向关联吗
- C----能用其他手段交叉检查一下结果吗
- E----你是否可以强制错误条件发生
- P----是否满足性能要求
Right
测试的结果是否正确.但是在代码的整个生命周期中,"正确"的定义可能会不断在变;但是无论如何,你至少需要确认代码所做的和你的期望是一致的.
对于许多有大量测试数据的测试,使用一个独立的数据文件来存储这些测试数据,然后让单元测试读取该文件.(使用JSON数据是个不错的选择)
边界条件
一个想到可能得边界条件的简单办法就是记住CORRECT.
- Conformance(一致性)----值是否和预期的一致
- Ordering(顺序性)----值是否如应该的那样,是有序或者无序的
- Range(区间性)----值是否位于合理的最大值和最小值之内.
- Reference(依赖性)----代码是否引用了一些不在代码本身控制范围之内的外部资源
- Existence(存在性)----值是否存在(例如,是否为非null,非0,在一个集合中等等)
- Cardinatity(基数性)----是否恰好有足够的值
- Time(相对或者绝对的时间性)----所有事情的发生是否是有序的?是否是在正确的时刻?是否恰好及时?
找出还有什么会出错
基数性也称为集合的势,指集合包含的元素的个数
检查反向关联
为了检查某条记录是否成功地插入了数据库,可以通过查询这条记录来验证
使用其他手段来实现交叉检查
通常而言,计算一个量会有一种以上的算法.我们可能会基于运行效率或者其他的特性,来选择算法.那是我们要在产品中使用的;但是在测试用的系统中,可能使用剩下算法中的一个来交叉测试结果.当确实存在一种经过验证并能完成任务的算法,只是由于速度太慢或者不太灵活而没有在产品代码中使用时,这种交叉检查的技术将非常有效.
强制产生错误条件
能想到的环境方面的因素
- 内存耗光
- 磁盘用满
- 时钟出问题
- 网络不可用或者有问题
- 系统过载
- 调色板颜色数目有限
- 显示分辨率过高或者过低
性能特性
一些粗糙的测试来确保性能曲线保持稳定.
junitperf可以模拟高负载情况.但是现在大多使用专门的性能测试工具,如Jmeter,loadrunner等
使用Mock对象
单元测试的目标是一次只验证一个方法，但是倘若遇到这样的情况：某个方法依赖于其他一些难以操控的东西，诸如网络、数据库等，将会发生什么情况呢？
在电影和电视制作中，工作人员通常会为真正的演员提供一些替身。具体来说，当摄影师在调整灯光或者摄像机角度的时候，他们会使用灯光替身；即高度和体型都与真正的演员相像，但地位并不那么重要的人。
在单元测试中，我们也需要类似灯光替身一类的替代品：一种和真品非常接近的赝品。
为什么要Mock对象
- 真实对象具有不可确定的行为（产生不可预测的结果，如股票行情）
- 真实对象很难创建
- 真实对象的某些行为很难触发（如网络错误）
- 真实对象令程序的运行速度很慢
- 真实对象有（或者是）用户界面
- 测试需要询问真实对象它是如何被调用的（例如，测试可能需要验证某个回调函数是否被调用了）
- 真实对象实际上并不存在（当需要和其他开发小组，或者新的硬件系统打交道的时候，这是一个普遍问题）
使用关键
- 使用一个接口来描述这个对象
- 为产品代码实现这个接口
- 以测试为目的，在mock对象中实现这个接口
http://www.mockobjects.commockobjects框架可以轻松帮助我们mock对象，同时这个网站的出品的关于测试的书：【Growing Object-Oriented Software Guided By Tests】
http://www.easymock.org github star 600+ 最近更新22天前
https://site.mockito.org/ github star 9.8k 最近更新3天前
http://powermock.github.io/http://powermock.github.io/ github star 2.9k 最近更新两个月前
好的测试所具有的品质
单元测试是非常有威力的魔法，当时如果使用不当也会浪费你大量的时间，从而对项目造成巨大的影响。另一方面，如果没有恰当地编写和实现单元测试，在维护和调试这些测试上面，很容易就会浪费很多的时间，从而影响产品代码和整个项目。
好的测试应该具有以下的品质，合称为A-TRIP
- 自动化（Automatic）
- 彻底的（Thorough）
- 可重复（Repeatable）
- 独立的（Independent）
- 专业的（Professional）
Where
并行树
把测试类放入和产品代码的同一个包中，但应位于不同的源代码树。确保两棵树的根都在编译器的CLASSPATH中。
在项目中进行测试
测试的礼貌
当与小组成员一同工作时，我们应该避免签入这样的代码：
- 不完整的代码（比如，仅签入了一个类文件，而忘记签入它所依赖的其他文件）
- 不能编译的代码
- 代码能编译，但是会破坏已经存在的代码，比如使得已经存在得代码编译失败
- 没有相应单元测试的代码
- 不能通过单元测试的代码
- 通过了自己得测试，但是导致系统其他地方的其他测试失败的代码
测试的频率
- 编写新的函数
- 修正bug
- 每次成功编译之后
- 每次对版本控制的签入
- 持续不断地（专门的机器，SonarQube）
使用Junit的单元测试来做回归测试
测试与评审
让测试代码成为评审过程的一个组成部分。
在编写产品代码之前，同时编写和评审测试。也就是说，编码和评审以这样的顺序进行：
- 编写test case 和/或 测试代码
- 评审test case 和/或 测试代码
- 经评审修改test case和/或 测试代码
- 编写能通过所有测试的产品代码
- 评审产品代码和测试代码
- 在每次评审后，修改测试代码和产品代码
有关设计的话题
面向测试的设计
通过使用面向测试的设计方法,更好的分离关注点
实际上你只需要在编写代码的时候.记住下面这个根本性的问题就可以了.
我要如何对代码进行测试呢
如果答案并不那么显而易见,或者测试代码看起来写得非常丑陋,甚至难以编写的话,那么你就应该把这种情况看成一种征兆.他暗示着你的设计可能需要修改,改变一些设计,直到让代码易于测试为止.最后通过这些努力,你的设计一定会好很多.
为测试而重构
测试类的不变性
类的不变性是指一个或者几个针对类对象的断言.如果一个类对象有效的话,这些断言都必须为真.这一点是不可改变的.
例如对一个实现了sorted list的类,它的不变性就是:它的内容必须是有序的.
适合应用类的不变性的领域:
- 结构化(数组的index必须大于等于0)
- 数学不变性(不同单位计算出来的总数必须一致)
- 数据一致性(收-支=结余)
通过定义类不变性更好的阐明设计意图
测试驱动的设计TDD
如果你总是在编写实现代码之前,就先编写他们的测试代码,那么你就是在使用测试驱动开发.
通过使用测试驱动的设计方法,改善接口的设计
测试无效的参数
对于输入的参数我们应该在系统入口的位置就检查输入,这样在系统的内部也就不需要再次检查.也就是说,如果数据能够通过入口的检查,并且深入到系统的内部,那么系统内部的组件也就可以信任这些输入数据了.
如果你的代码不负责对他们进行检查,那么就不必在检查他们上面浪费时间.而如果是你的责任,那么就需要加倍的警惕----因为现在系统中的其余部分完全依赖于你的检查结果,并且只依赖于你的检查结果.
确立和局部化验证的责任
误区
- 只要代码能工作就可以(单元测试不通过也无所谓)
- 冒烟测试已经足够了
- 请让我的机器来运行!(存在着和环境相关的bug) 所有的测试必须能够在所有的机器通过
- 浮点数问题(Junit的浮点数断言要求你指定一个精度用来近似地比较两个值)断言两个浮点数打印相同但是结果报错
- 测试耗费的时间太多了(耗时时间长的测试,增加测试间隔)
- 测试总是失败(一些小的改动立刻令很多测试失败,这实际上是一种过度耦合的迹象,要么重构,要么Mcok对象)
- 在某些机器上测试失败(bug,运行速度,时间片分配的差异等)
注重实效的单元测试:总结
一般原则
- 测试任何可能失败的地方
- 测试任何已经失败的地方
- 对于新加的代码,在被证明正确之前,都可能是有问题的
- 至少编写和产品代码一样多的测试代码
- 针对每次编译都做局部测试
- 签入代码之前做全局测试
要回答的问题
- 我如何知道代码运行是否正确呢?
- 我要如何对它进行测试?
- 还有哪些方面可能会发生错误?
- 这个问题是否会在其他的地方出现呢?
测试哪些方面:使用你的RIGHT-BICEP
- 结果是否正确(RIGHT)?
- 边界(boundary)条件是否正确?
- 是否可以检查反向(inverse)关联?
- 是否可以使用其他方法来跨检查(cross-check)结果?
- 错误条件(error condition)是否可以重现?
- 性能方面是否满足条件?
好的测试是 A TRIP
- Automatic(自动的)
- Thorough(全面的)
- Repeatable(可重复的)
- Independent(独立的)
- Professional(专业的)
CORRECT边界条件
- 一致性(Conformance)----值是否符合预期的格式
- 有序性(Ordering)----一组值是该有序的,还是该无序的?
- 区间性(Range)----值是否在一个合理的最大值和最小值的范围之内?
- 引用、耦合性(Reference)----代码是否引用了一些不受代码本身直接控制的外部因素?
- 存在性(Existence)----值是否存在(例如,非null,非零,包含于某个集合等)?
- 基数性(Cardinality)----是否恰好有足够的值?
- 时间性,绝对的或者相对的(Time)----所有事情是否都是按顺序发生的?是否在正确的时间?是否及时?
推荐方法
推荐的方法是：先完成黑盒测试，然后统计白盒覆盖率，针对未覆盖的逻辑单位设计测试用例覆盖它，例如，先检查是否有语句未覆盖，有的话设计测试用例覆盖它，然后用同样方法完成条件覆盖、分支覆盖和路径覆盖，这样的话，既检验了黑盒测试的完整性，又避免了重复的工作，用较少的时间成本达到非常高的测试完整性。
路径覆盖的含义是，选取足够多的测试数据，使程序的每条可能路径都至少执行一次
测试工具
Java
JUnit
JUnit 是 Java 社区中知名度最高的单元测试工具。它诞生于 1997 年，由 Erich Gamma 和 Kent Beck 共同开发完成。其中 Erich Gamma 是经典著作《设计模式：可复用面向对象软件的基础》一书的作者之一，并在 Eclipse 中有很大的贡献；Kent Beck 则是一位极限编程（XP）方面的专家和先驱。JUnit 设计的非常小巧，但是功能却非常强大。JUnit ——是一个开发源代码的Java测试框架，用于编写和运行可重复的测试。他是用于单元测试框架体系xUnit的一个实例（用于java语言）。主要用于白盒测试，回归测试。
JUnit的好处和JUnit单元测试编写原则：
好处：可以使测试代码与产品代码分开；针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试；易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发；JUnit是公开源代码的，可以进行二次开发；可以方便地对JUnit进行扩展；
编写原则：是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；是使测试单元保持持久性；是可以利用既有的测试来编写相关的测试；
JUnit-addons
对JUnit的一些补充，比如设置、获取被测试对象的私有属性的值，调用被测试对象的私有方法等。
常用类：junitx.util.PrivateAccessor
Spring 测试框架
可以测试基于Spring的应用，通过配置文件和注解自动组装需要的单元测试对象。
提供了一些常用的J2EE Mock对象，比如HttpSession的Mock类等。
可以支持数据库自动回滚，以防止对数据库的单元测试（插入，删除等）不可重复执行，防止修改数据库状态等。
国内现状
大部分业务可以确定下来，但并非全部的业务。很多时候连客户不知道自己真正要什么，实现了之后客户不满意，就要再整理需求再改代码。这种情况决定了不可能先写测试再写实现，如果只写实现，那么客户要求改时只改实现代码，如果是先写单元测试，那么改程序的时候要改两份代码。
应用
极限编程
单元测试是极限编程的基础，依赖于自动化的单元测试框架。
极限编程的商业实践之一：测试驱动开发—TDD
技术
单元测试会激发程序员创造解耦的和内聚的代码体。单元测试实践有利于促进健康的软件开发习惯。设计模式、单元测试和重构经常一起出现在工作中，借助于它们，开发人员可以生产出最为完美的解决方案
单元测试框架
单元测试框架通常是没有作为编译器包的第三方产品。他们帮助简化单元测试的过程，并且已经为各种编程语言开发。
语言层单元测试支持
某些编程语言直接支持单元测试。他们的语法允许直接进行单元测试的声明而不需要导入（不管是第三方的或标准的）。除此之外，单元测试的布尔条件可以用与非单元测试码的布尔表示法相同的语法来表示，例如if和while声明的用法。
如何写出好的单元测试
- 保持测试代码的紧凑和可读性
- 避免编写重复累赘的断言
- 覆盖尽可能多的范围，包括正面情况，以及（甚至更重要的）出错的代码路径。
- 不要Mock你不拥有的类型！
- 不要Mock一切，这是一种反模式
- 读《The Growing Object Oriented Software Guided by Tests》这本书
阿里开发手册单元测试相关规定:
三、单元测试
1.【强制】好的单元测试必须遵守AIR原则。
说明：单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。
- A：Automatic（自动化）
- I：Independent（独立性）
- R：Repeatable（可重复）
2.【强制】单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用System.out来进行人肉验证，必须使用assert来验证。
3.【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。
反例：method2需要依赖method1的执行，将执行结果作为method2的输入。
4.【强制】单元测试是可以重复执行的，不能受到外界环境的影响。
说明：单元测试通常会被放到持续集成中，每次有代码check in时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。
正例：为了不受外界环境影响，要求设计代码时就把SUT的依赖改成注入，在测试时用spring 这样的DI框架注入一个本地（内存）实现或者Mock实现。
被测系统(System under test, SUT)表示正在被测试的系统
5.【强制】对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别。
说明：只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域.
6.【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。
说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。
7.【强制】单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下。
说明：源码编译时会跳过此目录，而单元测试框架默认是扫描此目录。
8.【推荐】单元测试的基本目标：语句覆盖率达到70%；核心模块的语句覆盖率和分支覆盖率都要达到100%
说明：在工程规约的应用分层中提到的DAO层，Manager层，可重用度高的Service，都应该进行单元测试。
9.【推荐】编写单元测试代码遵守BCDE原则，以保证被测试模块的交付质量。
- B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
- C：Correct，正确的输入，并得到预期的结果。
- D：Design，与设计文档相结合，来编写单元测试。
- E：Error，强制错误信息输入（如：非法数据、异常流程、业务允许外等），并得到预期的结果。
10.【推荐】对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。
反例：删除某一行数据的单元测试，在数据库中，先直接手动增加一行作为删除目标，但是这一行新增数据并不符合业务插入规则，导致测试结果异常。
11.【推荐】和数据库相关的单元测试，可以设定自动回滚机制，不给数据库造成脏数据。或者对单元测试产生的数据有明确的前后缀标识。
正例：在企业智能事业部的内部单元测试中，使用ENTERPRISE_INTELLIGENCE _UNIT_TEST_的前缀来标识单元测试相关代码。
12.【推荐】对于不可测的代码在适当的时机做必要的重构，使代码变得可测，避免为了达到测试要求而书写不规范测试代码。
13.【推荐】在设计评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好覆盖所有测试用例。
14.【推荐】单元测试作为一种质量保障手段，在项目提测前完成单元测试，不建议项目发布后补充单元测试用例。
15.【参考】为了更方便地进行单元测试，业务代码应避免以下情况：
- 构造方法中做的事情过多。
- 存在过多的全局变量和静态方法。
- 存在过多的外部依赖。
- 存在过多的条件语句。
说明：多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。
16.【参考】不要对单元测试存在如下误解：
- 那是测试同学干的事情。本文是开发手册，凡是本文内容都是与开发同学强相关的。
- 单元测试代码是多余的。系统的整体功能与各单元部件的测试正常与否是强相关的。
- 单元测试代码不需要维护。一年半载后，那么单元测试几乎处于废弃状态。
- 单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。
程序员修炼三部曲(单元测试之道、版本控制之道、项目自动化之道) ；本文内容参考【单元测试之道】和【阿里开发手册】