前言

这几天正在成都出差，欣赏着成都的妹纸。

当我开始写这篇的时候是上周五，没想到这么快就星期二了，东西越写越多，为了保持文章尽量短小精悍，Juint的详细用法就分成多篇来写把，具体能写几篇我也不清楚...

正文

现在我们看是介绍Junit的用法，如果你想看看官方的介绍，可以访问http://junit.org/junit4/。

Assertions（断言）

断言我们之前已经在demo中使用过了，他的作用就是明确我们期望发生的情况，如果不满足就会报错，就是一种突然成为上帝的感觉，不符合条件的情况我们就不允许发生。

Junit中断言有好几种，从字面我们就可以知道他们的用途，例如

assertArrayEquals：断言两个数组是否相等
assertEquals：断言字符串是否相等
assertTrue：断言判断为true
assertNotNull：断言不为空
assertSame：断言相同

他们还有相反的断言，例如assertEquals，对应就有assertNotEquals，这里就不全都列举出来了。

断言最多有三个参数：

String reason: 描述要测试的原因，此参数可以省略
T actual：要判断的参数
T matcher：对比的参数

其中稍微复杂一点的assertThat，他相当于上面列举的断言的升级版，他更加灵活，接下来我们举一个例子：

int x = 3;
assertThat("assertThat good", "good", is("good"));
assertEquals("assertEquals good", "good", "good");
assertThat(x, is(3));

上面的代码中，我们通过assertThat，assertEquals都去判断同一个字符串是否相等，第三个断言是判断整型是否相等。

运行之后没有报错，说明assertThat，assertEquals都测试通过了，这两种用法得到的结果是相同的。

assertThat只能判断相同类型，例如要判断的参数为int型，对比的参数也只能是int型。对比的参数要使用Matcher参数，类似于一个判断语句，比如的有：

is()：相当于 “是” 的意思
not（）：相当于 “不是的意思”

ok，以上就是断言的用法，通常我们没有必要使用assertThat，其他的断言几乎可以满足我们所有的需求，但是我们仍然要牢记他的用法。

Test Runners

我没想到一个特别合适的词来形容Test Runners的作用，所以多说几句：

Test Runners 是具有特殊功能的执行测试用例的通道，也可以理解为测试的执行者，例如可以同时运行多个测试用例，也可以具有这个测试执行者特有的功能。

用法1

/**
 *      Test Runner 示例代码
 */
public class TestRunnerDemo {
    @Test
    public void runnerTest(){
        org.junit.runner.JUnitCore.runClasses(ExampleUnitTest.class, StudentTest.class);
    }
}

我们可以通过org.junit.runner.JUnitCore.runClasses()方法来同时运行多个测试class文件，里面的参数个数是随意的，例如示例代码中按照顺序运行了ExampleUnitTest.class和StudentTest.class。

用法2

/**
 *      Test Runner 实例代码2
 */
@RunWith(Suite.class)
// 绑定的测试用例集合
@Suite.SuiteClasses({ExampleUnitTest.class, StudentTest.class})
public class TestRunnerDemo2 {
}

通过注解@RunWith与其他测试用例进行绑定，然后@Suite.SuiteClasses({ExampleUnitTest.class, StudentTest.class})来设置绑定的测试用例的集合，当运行这个测试用例的时候，绑定的集合也会运行。

用法3

package com.lzp.unittestdemo.testrunner;

import com.lzp.unittestdemo.Utils;

import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

import java.util.Arrays;
import java.util.Collection;

/**
 * <p>
 * Test Runner 示例代码3
 */
@RunWith(Parameterized.class)
public class TestRunnerDemo3 {

    /**
     * name可以用来描述这个测试的信息
     * 其中{index}表示当前的索引值，因为执行的时候会遍历集合
     * {0} 表示参数键值对的第一个位置
     * {1} 表示参数键值对的第二个位置，坐标以此类推
     */
    @Parameters()
    public static Collection<Object[]> data() {
        return Arrays.asList(new Object[][]{
                {0, 0}, {1, 1}, {2, 1}, {3, 2}, {4, 3}, {5, 5}, {6, 8}
        });
    }

    private int fInput;

    private int fExpected;

    /**
     * 这里模拟了创建对象的过程，Juit会自动把@Parameters里面的数据集合，按照顺序依次放入构造方法中
     * */
    public TestRunnerDemo3(int input, int expected) {
        fInput = input;
        fExpected = expected;
        System.out.println(input + " ：" + expected);
    }

    /**
     * 测试方法，通过Assert.assertEquals判断参数是否符合我们的期望
     * */
    @Test
    public void test() {
        Assert.assertEquals(fExpected, Utils.compute(fInput));
    }
}

使用@RunWith(Parameterized.class)会稍微复杂一点，但是使用起来非常的方便，我们可以创建很多个相同类型的对象，然后通过测试方法对属性进行操作，验证我们创建的类是否符合我们的期望。

用法4

@RunWith(Categories.class)
// 为这个测试添加分类
@Category(MyCategory.class)
// 绑定的测试类集合
@Suite.SuiteClasses( { TestRunnerDemo.class, TestRunnerDemo3.class })
// 交集，运行SuiteClasses中与自己分类相同的测试类
//@Categories.IncludeCategory(MyCategory.class)
// 除去交集，运行SuiteClasses中与自己分类不同的测试类
@Categories.ExcludeCategory(MyCategory.class)
public class TestRunnerDemo4 {
    @Test
    public void test(){
        assertEquals(4, 2 + 2);
    }
}

使用@Category可以对测试类添加分类，然后和@Suit结合使用，可以同时运行相同分类或不同分类的测试，算是上一种用法的升级版。

用法5

有时候我们会把测试方法卸载内部类中，这个时候我们需要使用@RunWith(Enclosed.class)，这样可以运行内部类的测试方法， 这里贴出官方的demo连接：https://github.com/junit-team/junit4/wiki/%27Enclosed%27-test-runner-example，大家可以学习一下。

用法6

使用第三方的Test Runner：

这里写图片描述

这是官网的举例，之后我们会用到MockitoJUnitRunner，其他的大家可以自己去百度学习一下如何使用。

Test execution order（测试运行顺序）

有时候我们需要一些测试按照我们期望的顺序进行，例如对同一个属性按照某个顺序多次加工，我们想要看到最终的结果，这种情况下，我们可以使用@FixMethodOrder()。

@FixMethodOrder() 指明类中测试方法的运行顺序。

MethodSorters.DEFAULT：不可预测的顺序，可以认为是随机的顺序。
MethodSorters.JVM：按照JVM编译的顺序，顺序也可能发生变化
MethodSorters.NAME_ASCENDING：按照方法的命名的顺序，也就是按照字母的顺序，从a到z。

@FixMethodOrder(MethodSorters.DEFAULT)
public class TestMethodOrder {

    @Test
    public void testA() {
        System.out.println("first");
    }
    
    @Test
    public void testC() {
        System.out.println("third");
    }

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

    
}

上面是官方的demo，为了让测试结果更明显，我把testC()移动到了第一位，看一下运行结果：

这里写图片描述

从截图上看，确实是按照A、B、C的顺序执行。

总结

今天就到此为止，东西不难，但是知识点还是挺多的，都需要我们慢慢消化，我也是用的时候，偶尔还得复习一遍。

听同事说今天立冬，啥也别说了，先填饱我的肚子把，各位拜拜~