单元测试的理解和应用

2018-06-10 本文已影响0人司大明明

基础

单元测试是什么？

单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行检验。单元测试几乎都是用单元测试框架编写的。单元测试容易编写，能快速运行。单元测试可靠、可读、并且可维护。只要产品代码不发生变化，单元测试的结果是稳定的。

简单来说就是，开发人员编写的一小段代码，用于检验被测代码的一个有明确功能的小模块是否正确。

通常用来判断某个类或者函数的行为
白盒测试
开发人员是最大受益者

特征是什么？

自动化，可重复执行
易实现
不会依赖于特定条件（比如：时间）
易使用
运行速度很快（毫秒级）
结果应该是稳定的
能完全控制被测试的单元
完全隔离（独立于其他测试的运行）

应用

例子：

示例

人肉测试

平时我们图方便想要测试类中某个方法，通常会用main方法去测试

main方法测试

单元测试框架

我们可以使用Junit单元测试框架去测试，可以让程序员按照规定去写测试用例，然后框架开启自动化的执行去执行测试用例

Junit测试

测试规定

测试类的名称通常以Test结尾
每个测试方法加注解@Test，Junit就知道这是一个测试用例，在运行中就会执行这个测试用例
使用Assert，让Junit去判断我们的实际结果和预想值是否一致

总的来说，我们只要按照规定去写代码，剩下的就交给框架去做，框架会找到这个测试用例，然后执行，最后用Assert去检查实际值和预想值是否一致。如果不一致，就出现了bug。

多个测试用例

使用Suite套件，即@RunWith(Suite.class)；在 @SuiteClasses中将需要的测试类如上方例子依次写入。在下方的V1AllTests.java类中用同样的方式将test.v1包内的测试类全部写入。这样的话，可以单独运行单个测试用例，某个包内的测试用例，全部的测试用例，可以进行粗细粒度的运行和管控。这样的设计使用了组合的设计模式。

Junit常用的几种断言

/** 判断预想值和实际值是否一致**/
Assert.assertEquals(expected, actual);
/** 判断对象是否为True**/
Assert.assertTrue(condition);
/** 判断对象是否为空**/
Assert.assertNotNull(object);
/** 判断两个数组是否相等**/
Assert.assertArrayEquals(expected, actual);

对Exception进行测试

两种对Exception测试的方法

两种特殊的方法

特殊方法的运行流程

在每次执行类中某个测试用例时，会先调用setup()，在执行完毕后调用tearDown()。主要是为了testEvaluate1()和testEvaluate1()是独立执行的，没有先后顺序，并且执行后互不影响。
如果这两个方法都引用了某个共享变量，防止两个方法对这个共享变量的修改，使用@Berore和@After注解的方法可以让两个方法的执行对双方不造成影响。

优点

验证行为

保证代码的正确性
回归测试：即使到了项目后期，我们仍有勇气去增加新功能，修改程序结构，而不用担心破坏重要功能
给重构带来保证

设计行为

测试驱动迫使我们从调用这的角度去观察和思考问题，迫使我们把代码设计成可测试的，松耦合的

文档行为

单元测试是一种无价的文档，精确地描述了代码的行为，是如何使用函数和类的最佳文档

单元测试是个团队行为

运行别人的测试用例：验证你的代码修改
别人运行你的测试用例：验证别人的代码修改

原则

测试代码和被测代码是同等重要的，需要被同时维护

测试代码不是附属品
不但要重构代码，也要重构单元测试

单元测试一定要隔离

一个测试用例的运行结果不能影响其他测试用例
测试用例不能相互依赖，应该能够以任何次序执行

单元测试一定是可以重复执行的

不能依赖环境的变化

保持单元测试的简单性和可读性

尽量对接口进行测试

单元测试应该可以迅速执行

给程序员提供及时的反馈
使用Mock对象对数据库，网络的依赖进行解耦

自动化单元测试

集成到build过程中