一、前言
 
定义：单元测试（unit testing）是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作
 
单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
 
单元测试从长期来看，可以提高代码质量，减少维护成本，降低重构难度。但是从短期来看，加大了工作量，对于进度紧张的项目中的开发人员来说，可能会成为不少的负担。
 
二、哪些代码需要写单元测试？
 
 
 
老板为我的代码付报酬，而不是测试，所以，我对此的价值观是——测试越少越好，少到你对你的代码质量达到了某种自信（我觉得这种的自信标准应该要高于业内的标准，当然，这种自信也可能是种自大）。如果我的编码生涯中不会犯这种典型的错误（如：在构造函数中设了个错误的值），那我就不会测试它。我倾向于去对那些有意义的错误做测试，所以，我对一些比较复杂的条件逻辑会异常地小心。当在一个团队中，我会非常小心的测试那些会让团队容易出错的代码。————StackOverflow上单元测试以及JUnit的创造者Kent Beck的回答
 
 
小结：
 
逻辑复杂的。
容易出错的。
不易理解的。即使是自己过段时间也会遗忘的，看不懂自己的代码，单元测试代码有助于理解代码的功能和需求
公共代码。比如自定义的所有http请求都会经过的拦截器；工具类等。
核心业务代码。一个产品里最核心最有业务价值的代码应该要有较高的单元测试覆盖率。
 
三、什么时候写单元测试？
 
写单元测试的时机不外乎三种情况：
 
1、在具体实现代码之前。这是测试驱动开发（TDD）所提倡的；
 
2、与具体实现代码同步进行。先写少量功能代码，紧接着写单元测试（重复这两个过程，直到完成功能代码开发）。其实这种方案跟第一种已经很接近，基本上功能代码开发完，单元测试也差不多完成了。
 
3、编写完功能代码再写单元测试。我的实践经验告诉我，事后编写的单元测试“粒度”都比较粗。对同样的功能代码，采取前两种方案的结果可能是用10个“小”的单测来覆盖，每个单测比较简单易懂，可读性可维护性都比较好（重构时单测的改动不大）；而第三种方案写的单测，往往是用1个“大”的单测来覆盖，这个单测逻辑就比较复杂，因为它要测的东西很多，可读性可维护性就比较差。
 
建议：推荐单元测试与具体实现代码同步进行这个方案的。只有对需求有一定的理解后才能知道什么是代码的正确性，才能写出有效的单元测试来验证正确性，而能写出一些功能代码则说明对需求有一定理解了。
 
四、单元测试的好处？
 
1）让我们对自己的代码有信心
 
修改了代码后单测依然通过的，起码说明我们的修改没有破坏程序的正确性。这从主观上能增加我们对代码的信心。虽然单元测试通过了并不意味着程序就没有bug了，但我们也要了解到这可能不是单元测试的问题。单元测试顾名思义是测试一个”单元”，这个”单元”一般是类或方法，而不是整个系统。对整个系统的测试那是集成测试，功能测试的职责。单元测试追求的是快速反馈，频繁执行。集成测试虽然测“全局”，但成本较高，所以执行频率较少。两者使用场景不同，目的不同。
 
2）为代码重构保驾护航
 
看到代码很差劲，想重构，但又担心重构之后出问题，怎么办呢？如果有单元测试情况就不一样了，重构完代码，跑一遍单元测试，如果单元测试都通过，基本上可以保证我们的重构没有破坏原来代码逻辑的正确性。不过前提是之前的写的单元测试质量很好，覆盖率很高。当然这仅限于小范围的重构，比如重构一个类或者函数的实现，但对于大刀阔斧的重构（比如单体重构成微服务，面向库表模式重构成DDD），就不适用，那个时候要重写单元测试了。
 
3）快速熟悉代码
 
单元测试不仅起到了测试的作用，还是一种很好的“文档”，通过单元测试，我们不需要深入的阅读代码，便能知道这段代码做什么工作，有哪些特殊情况需要考虑，包含哪些业务。
 
参考
 
单元测试系列一-为什么要写单元测试，何时写，写多细

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击http://www.captainbed.net
 
1、单元测试：完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误。通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
 
2、集成测试：通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。
 
自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
 
自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，集成时要求所有隶属于某个顶层的模块总是存在的，也不再有使用稳定测试桩的必要。
 
3、系统测试：是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
 
4、回归测试：回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。
 
5、验收测试：验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。
 
Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。
 
Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击http://www.captainbed.net
 
这些测试步骤分别在软件开发的不同阶段对软件进行测试，个人认为对软件完整功能进行测试的系统测试最重要。因为此时单元测试和集成测试已经完成，系统测试能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此系统测试最重要。

参考文章地址地址：JUnit4单元测试入门教程
 
                                IDEA单元测试及代码覆盖率
 
                                                IDEA添加jar包的三种方式
 
 
 
 
 
本文按以下顺序讲解JUnit4的使用
 
下载jar包
单元测试初体验
自动生成测试类
执行顺序
@Test的属性
代码覆盖率
下载jar包
 
在github上，把以下两个jar包都下载下来。下载地址：点击打开链接
 

 
 

   
 
 
 
下载junit-4.12.jar，junit-4.12-javadoc.jar（文档），junit-4.12-sources.jar（源码）。
 

 
 

   
 
 
 
下载hamcrest-core-1.3.jar，hamcrest-core-1.3-javadoc.jar（文档），hamcrest-core-1.3-sources.jar（源码）。
 

 
 

   
 
 
 
最前面那个pom是Maven的配置文件，如果你需要的话也下载下来。
 
 
 
单元测试初体验
 
先创建个简单的项目体验下单元测试是怎么一回事吧。
 
我创建一个项目叫JUnit4Demo，刚创建好的工程目录如下图，然后在External Libraries中导入刚下载的那两个jar包。
 
                        
 
通过Libraries添加Jar包
 
1.打开 File -> Project Structure ->Modules-> 在Dependencies 下添加jar包
 
              
 
2、+ -> Library... -> java -> 选择jar的路径添加。   添加jar包后如下图所示。
 
                   
 
3、创建一个类com.hera.util.Math，然后输入一个求阶乘的方法：
 
                    
 
4、创建一个队Math方法的单元测试：
 
        创建一个和src同级别的文件夹叫test(逻辑代码放src里，测试代码放test里是个好习惯)。
         接着在IntelliJ IDEA里还要把这个test文件夹要设置成测试文件的根目录，右键选中
         Mark Directory As - Test Sources Root。
 
                                     
            创建一个测试类：
 
            IntelliJ IDEA提供了一个快捷操作Cmd + Shift + T作为类和测试之间的导航。同时允许用户在那里创建一个测试类。IntelliJ IDEA提供了一个快捷操作Cmd + Shift + T作为类和测试之间的导航。同时允许用户在那里创建一个测试类。
 
          为测试类MathTest添加测试方法：
 
              
 
                 
 
                运行： run MathTest 。右下方一条绿色条说明测试通过，如果把120改成别的数字那么就会测试不通过显色红色条。JUnit4有一句话叫：“keeps the bar green to keep the code clean”。
 
        解释一下MathTest，就六个地方要讲：
                   第一，导入了org.junit.Test;和org.junit.Assert.*;这两个包，注意后者是静态导入import static。
                   第二，testFactorial是在要测试的方法名Factorial前加个test（这也是个好习惯）。
                   第三，所有测试方法返回类型必须为void且无参数。
                   第四，一个测试方法之所以是个测试方法是因为@Test这个注解。
                   第五，assertEquals的作用是判断两个参数是否相等，例子中120是预期结果，new Math().factorial(5)是实                              际结果。但是通常不应该只比较一个值，要测试多几个特殊值，特别是临界值。
 
                            例如Math().factorial(0)和Math().factorial(-1)等。
                  第六，assertEquals除了比较两个int，还重载了好多次可以比较很多种类型的参数。而且JUnit4包含一堆                                assertXX方法，assertEquals只是其中之一，这些assertXX统称为断言。刚不是下载了junit-4.12-                                 javadoc.jar这个文档吗，解压后打开index.html如下图还有一堆断言。
 
                   
 
      
 
执行顺序
 
 
 
JUnit4利用JDK5的新特性Annotation，使用注解来定义测试规则。
 这里讲一下以下几个常用的注解：
 
@Test：把一个方法标记为测试方法
@Before：每一个测试方法执行前自动调用一次
@After：每一个测试方法执行完自动调用一次
@BeforeClass：所有测试方法执行前执行一次，在测试类还没有实例化就已经被加载，所以用static修饰
@AfterClass：所有测试方法执行完执行一次，在测试类还没有实例化就已经被加载，所以用static修饰
@Ignore：暂不执行该测试方法
 
 
我们来试验一下，我新建一个测试类AnnotationTest，然后每个注解都用了，其中有两个用@Test标记的方法分别是test1和test2，还有一个用@Ignore标记的方法test3。然后我还创建了一个构造方法，这个构造方法很重要一会会引出一个问题。
 具体代码如下：
 

package com.xuhongchuan.util;

import org.junit.*;
import static org.junit.Assert.*;

/**
 * Created by xuhongchuan on 2015/7/18.
 */
public class AnnotationTest {

    public AnnotationTest() {
        System.out.println("构造方法");
    }

    @BeforeClass
    public static void setUpBeforeClass() {
        System.out.println("BeforeClass");
    }

    @AfterClass
    public static void tearDownAfterClass() {
        System.out.println("AfterClass");
    }

    @Before
    public void setUp() {
        System.out.println("Before");
    }

    @After
    public void tearDown() {
        System.out.println("After");
    }

    @Test
    public void test1() {
        System.out.println("test1");
    }

    @Test
    public void test2() {
        System.out.println("test2");
    }

    @Ignore
    public void test3() {
        System.out.println("test3");
    }

}
 
运行结果如下：
 
BeforeClass
构造方法
Before
test1
After
构造方法
Before
test2
After
AfterClass
 
 
 
        解释一下：@BeforeClass和@AfterClass在类被实例化前（构造方法执行前）就被调用了，而且只执行一次，通常用来初始化和关闭资源。@Before和@After和在每个@Test执行前后都会被执行一次。@Test标记一个方法为测试方法没什么好说的，被@Ignore标记的测试方法不会被执行，例如这个模块还没完成或者现在想测试别的不想测试这一块。
        以上有一个问题，构造方法居然被执行了两次。所以我这里要说明一下，JUnit4为了保证每个测试方法都是单元测试，是独立的互不影响。所以每个测试方法执行前都会重新实例化测试类。
       我再给你看一个实验：
 
 
 
 
 
 
 
 
 
      添加一个成员变量
 
 
 
 
 

int i = 0;
 
 
 
然后把test1改为：
 
    i++;
    System.out.println("test1的i为" + i);
 
test2改为：
 
    i++;
    System.out.println("test2的i为" + i);
 
执行结果：
 
BeforeClass
构造方法
Before
test1的i为1
After
构造方法
Before
test2的i为1
After
AfterClass
 
 
 
       可以看到test1和test2的i都只自增了一次，所以test1的执行不会影响test2，因为执行test2时又把测试类重新实例化了一遍。如果你希望test2的执行受test1的影响怎么办呢？把int i改为static的呗。
 
        最后关于这些注解还有一个要说明的就是，你可以把多个方法标记为@BeforeClass、@AfterClass、@Before、@After。他们都会在相应阶段被执行。
 
 
 
 
 
@Test的属性
 
 
 
最后来说一下@Test的两个属性
 
excepted
timeout
excepted属性是用来测试异常的，我们回到Math类，拿其中的求阶乘方法factorial()来说。如果传进来一个负数我们是希望抛出异常的，那要测试会不会抛异常怎么办呢？
我在测试类MathTest添加一个测试方法：    
               
          这个方法就是(expected = Exception.class)和fail("factorial参数为负数没有抛出异常");之间的配合。就是这个测试方法会检查是否抛出Exception异常（当然也可以检测是否抛出其它异常），如果抛出了异常那么测试通过（因为你的预期就是传进负数会抛出异常）。没有抛出异常则测试不通过执行fail("factorial参数为负数没有抛出异常");
 
 
 
 
 

          
 然后说下timeout属性，这个是用来测试性能的，就是测试一个方法能不能在规定时间内完成。
 

 回到Math类，我创建一个数组排序的方法，用的是冒泡排序。
 
 
 
 
 

          
 
public void sort(int[] arr) {
    //冒泡排序
    for (int i = 0; i < arr.length - 1; i++) { //控制比较轮数

        for (int j = 0; j < arr.length - i - 1; j++) { //控制每轮的两两比较次数
            if (arr[j] > arr[j + 1]) {
                int temp = arr[j];
                arr[j] = arr[j + 1];
                arr[j + 1] = temp;
            }
        }
    }
}
 
 

       然后偶在测试类MathTest创建测试方法，随机生成一个长度为50000的数组然后测试排序所用时间。timeout的值为2000，单位和毫秒，也就是说超出2秒将视为测试不通过。
 
 
 
@Test(timeout = 2000)
public void testSort() throws Exception {
    int[] arr = new int[50000]; //数组长度为50000
    int arrLength = arr.length;
    //随机生成数组元素
    Random r = new Random();
    for (int i = 0; i < arrLength; i++) {
        arr[i] = r.nextInt(arrLength);
    }

    new Math().sort(arr);
}
       
 运行结果测试不通过，且提示TestTimedOutException。
 

       那怎么办，修改代码提升性能呗。回到Math方法改为下sort()。这次我用快速排序，代码如下：
 
 
 
public void sort(int[] arr) {
    //快速排序
    if (arr.length <= 1) {
        return;
    } else {
        partition(arr, 0, arr.length - 1);
    }
}

static void partition(int[] arr, int left, int right) {
    int i = left;
    int j = right;
    int pivotKey = arr[left]; //基准数

    while (i < j) {
        while (i < j && arr[j] >= pivotKey) {
            j--;
        }

        while (i < j && arr[i] <= pivotKey) {
            i++;
        }

        if (i < j) {
            int temp = arr[i];
            arr[i] = arr[j];
            arr[j] = temp;
        }
    }

    if (i != left) {
        arr[left] = arr[i];
        arr[i] = pivotKey;
    }

    if (i - left > 1) {
        partition(arr, left, i - 1);
    }

    if (right - j > 1) {
        partition(arr, j + 1, right);
    }

}
 
          然后再运行一下测试类MathTest，绿色条出现了，测试通过妥妥的。
 
 
 
 
 
 
 
 
 
编辑测试设置
 
 
       我们可以通过Run → Edit Configurations或工具栏上的标签来调整我们的测试运行配置。
 
 
        
 
 
 
 
 
       在Configuration选项卡,用户可以选择需要运行的测试。例如,您可以从一个类、程序包、测试套件或甚至模式中运行所有的测试。这里的Fork模式让用户在一个单独的进程运行每个测试。
 
 
 
 
 
        在代码覆盖标签你可以调整覆盖率设置。目前IntelliJ IDEA支持两种测量覆盖率引擎。默认情况下它使用自己的引擎，当然用户也可以选择JaCoCo引擎。用户也可以在这里选择覆盖率模式。Tracing{span{ mode模式会增加消耗,但测量会更精确。
 
 
                 
 
 
运行覆盖
 
 
         收集覆盖率,用户需要通过Run → Run 'MyClassTest' with Coverage或工具栏上的选项运行特定模式的测试。
 
 
        当覆盖模式运行至少一个测试之后,IDE将会在Project工具窗口显示每个程序包、类的覆盖率数据，同时在Coverage工具窗和编辑器中也会显示。
 
 
         
 
 
 
 
 
编辑器中的覆盖率
 
 
如果用户添加另一个方法到MyClass，并运行覆盖率测MyClass,就会发现,没有被测试覆盖到的代码都将高亮显示为红色。覆盖的代码颜色则是绿色。如果一些代码是只覆盖部分,那没将显示为黄色。