基础
单元测试是什么？
单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行检验。单元测试几乎都是用单元测试框架编写的。单元测试容易编写，能快速运行。单元测试可靠、可读、并且可维护。只要产品代码不发生变化，单元测试的结果是稳定的。
简单来说就是，开发人员编写的一小段代码，用于检验被测代码的一个有明确功能的小模块是否正确。
1.通常用来判断某个类或者函数的行为
2.白盒测试
3.开发人员是最大受益者
特征是什么？
1.自动化，可重复执行
2.易实现
3.不会依赖于特定条件（比如：时间）
4.易使用
5.运行速度很快（毫秒级）
6.结果应该是稳定的
7.能完全控制被测试的单元
8.完全隔离（独立于其他测试的运行）
应用
例子：
示例
人肉测试
平时我们图方便想要测试类中某个方法，通常会用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注解的方法可以让两个方法的执行对双方不造成影响。
优点
验证行为
1.保证代码的正确性
2.回归测试：即使到了项目后期，我们仍有勇气去增加新功能，修改程序结构，而不用担心破坏重要功能
3.给重构带来保证
设计行为
测试驱动迫使我们从调用这的角度去观察和思考问题，迫使我们把代码设计成可测试的，松耦合的
文档行为
单元测试是一种无价的文档，精确地描述了代码的行为，是如何使用函数和类的最佳文档
单元测试是个团队行为
运行别人的测试用例：验证你的代码修改
别人运行你的测试用例：验证别人的代码修改
原则
测试代码和被测代码是同等重要的，需要被同时维护
测试代码不是附属品
不但要重构代码，也要重构单元测试
单元测试一定要隔离
一个测试用例的运行结果不能影响其他测试用例
测试用例不能相互依赖，应该能够以任何次序执行
单元测试一定是可以重复执行的
不能依赖环境的变化
保持单元测试的简单性和可读性
尽量对接口进行测试
单元测试应该可以迅速执行
给程序员提供及时的反馈
使用Mock对象对数据库，网络的依赖进行解耦
自动化单元测试
集成到build过程中
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
