JUnit測試控制@Test執(zhí)行順序

第一種

@FixMethodOrder(MethodSorters.JVM)

從上到下 執(zhí)行@Test

第二種（推薦）

@FixMethodOrder(MethodSorters.NAME_ASCENDING) 

按方法名字順序執(zhí)行@Test

第三種

@FixMethodOrder(MethodSorters.DEFAULT)

默認(rèn)方法，不可預(yù)期

Junit測試方法保證執(zhí)行順序

由于需要做自動(dòng)化測試，所以需要比較完善的單元測試。但是又因?yàn)槟承y試的執(zhí)行依賴另外一個(gè)測試產(chǎn)生的結(jié)果，所以希望所寫的test case按照自己希望的順序來執(zhí)行。

隨后博主查閱資料發(fā)現(xiàn)了FixMethodOrder注解，可以有三種方式可以控制test執(zhí)行順序。

　　/**
     * Sorts the test methods by the method name, in lexicographic order, with {@link Method#toString()} used as a tiebreaker
     */
    NAME_ASCENDING(MethodSorter.NAME_ASCENDING),
    /**
     * Leaves the test methods in the order returned by the JVM. Note that the order from the JVM may vary from run to run
     */
    JVM(null),
    /**
     * Sorts the test methods in a deterministic, but not predictable, order
     */
    DEFAULT(MethodSorter.DEFAULT);

大概上就是上面三種，很多大佬的博客上都對這幾種有講解以及示例，博主在這里就不啰嗦了，下面說一下我的一些疑問以及發(fā)現(xiàn)。

當(dāng)使用默認(rèn)排序時(shí)

@FixMethodOrder(MethodSorters.DEFAULT)
public class testDemo{
    
    @Test
    public void B(){
        System.out.println("b");
    }
    @Test
    public void C(){
        System.out.println("c");
    }
    @Test
    public void A(){
        System.out.println("a");
    }
    @Test
    public void AB(){
        System.out.println("ab");
    }
    @Test
    public void AC(){
        System.out.println("ac");
    }
    @Test
    public void A1(){
        System.out.println("a1");
    }
}

輸出

a
b
c
a1
ab
ac

這只是博主眾多測試結(jié)果中的一個(gè)，實(shí)際上與API中描述的“but not predictable”有所出入，執(zhí)行的順序是可預(yù)期的。

因?yàn)橛^察到，名字短的總排在前面，ascii碼小的總在前面，所以博主猜測有可能順序跟方法名字的字符串的hashcode有關(guān)的，于是加上hashcode方法輸出之后，得到結(jié)果：

方法A:65
方法B:66
方法C:67
方法A1:2064
方法AB:2081
方法AC:2082

所以可以得出結(jié)論，當(dāng)單元測試使用默認(rèn)執(zhí)行順序的時(shí)候，測試方法執(zhí)行的順序是跟測試方法名字符串的hashcode大小線性相關(guān)。

Junit執(zhí)行時(shí)應(yīng)該是把所有的有@test注釋的方法存到一個(gè)容器里，然后交由jvm去一一執(zhí)行（博主還沒來得及仔細(xì)去研讀Junit的源碼，這是本人的猜測）。那么問題來了，這一系列的方法是在同一個(gè)線程下還是多個(gè)線程一起執(zhí)行的呢？

其實(shí)從測試的執(zhí)行順序可以控制不難猜出，多個(gè)測試方法是串行執(zhí)行的，但是實(shí)踐才是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)。

代碼就不貼了，有興趣的同學(xué)可以自己寫一下看看，就是在第二順位執(zhí)行的方法那里讓他休眠一下，觀察是否也會(huì)阻塞第三個(gè)方法。

最終的結(jié)果也證明了猜想。

我現(xiàn)在看的還比較淺顯，有時(shí)間的話會(huì)去研讀Junit的底層源碼。以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家

最新評(píng)論