Android单元测试的利器:Juint(三):Juint的详细用法(上)

前言

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

当我开始写这篇的时候是上周五,没想到这么快就星期二了,东西越写越多,为了保持文章尽量短小精悍,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的顺序执行。

总结

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

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

猜你喜欢

转载自blog.csdn.net/u011315960/article/details/78434735