成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

探知JS測(cè)試(2)

jonh_felix / 3635人閱讀

摘要:針對(duì)于類型已經(jīng)出啦個(gè)方法來(lái)判斷在各種庫(kù)里,也出現(xiàn)了想等語(yǔ)義判斷。在斷言庫(kù)里,類型判斷也是必不可少的一部分。測(cè)試用例應(yīng)該會(huì)。在下一個(gè)測(cè)試套件內(nèi),還是依照默認(rèn)值。

前一篇文章,我們已經(jīng)簡(jiǎn)單的闡述了BDD,TDD以及mocha測(cè)試框架,chai斷言庫(kù). 這里我們將進(jìn)一步深入,比較全部的了解測(cè)試的API。
前文,我們已經(jīng)知道了,BDD本身可以比擬為文章的骨架,而chai斷言庫(kù)就是骨架里面的血管和肌肉(脂肪). 兩者結(jié)合才能寫出一片完美的測(cè)試文章。 這里,我們先看一下脂肪是怎么煉成的。

expect斷言

這里我針對(duì)expect斷言進(jìn)行一些講解,順便把一些比較重要的API,梳理一遍。
邏輯指示語(yǔ)法:

not
deep
any
all
and
not

取非語(yǔ)法

expect(1).to.not.equal(2); //pass
deep

深層檢查,該主要針對(duì)于對(duì)象和數(shù)組類型。 就好比復(fù)制一樣,分為深復(fù)制和淺復(fù)制. 通常情況下,我們直接比較的都是淺層.
像這樣的

//淺層比較
var expect = require("chai").expect;
var test1 = {
    foo:{
        bar:1
    }
}
var test2 = {
    bar:1
}
describe("Counter",function(){
    it("test",()=>{
        expect(test1.foo).to.equal(test2);
    })
})
//fail
//使用深層比較
describe("Test",function(){
    it("test",()=>{
        expect(test1.foo).to.deep.equal(test2);
    })
})
//pass
any

按正常語(yǔ)法看,這里就是任意的意思。通常搭配keys一起使用,用來(lái)表示或的意思。

expect(test1).to.have.any.keys("foo","bar");
all

這個(gè)語(yǔ)法和"any"的使用也差不多,也是用來(lái)表示keys的包含狀況

//test1對(duì)象的所有keys只有foo和bar
expect(test1).to.have.all.keys("foo","bar");

上面的邏輯語(yǔ)法通常和動(dòng)詞語(yǔ)法一起使用.
常用的動(dòng)詞語(yǔ)法有:

equal
include (alias: contain)
satisfy
match
change

通常,我們使用這里動(dòng)詞結(jié)合名詞來(lái)表達(dá)一個(gè)狀態(tài)

equal

顧名思義就是相等的意思唄。直接看一下demo

expect(1).to.equal(1);  //相等
expect(2).to.not.equal(3);  //不相等
include

包含的意思,其實(shí)他的alias還有contains,includes。 不過(guò)表達(dá)的都是一樣的意思,所以推薦直接使用include就可以了。include經(jīng)常和array,string,以及object使用. 正對(duì)于這3種類型,《包含》意味著:

array: 查詢是否包含子項(xiàng)
string: 查詢是否包含子字符串
object: 查詢是否包含子對(duì)象
//查詢array是否包含子項(xiàng)
expect([1,2,3,4,5]).to.include(3);
//包含sting的子串
expect("good").to.include("oo");
//判斷對(duì)象是否包含子對(duì)象
expect({first:1,second:2}).to.include({second:2})

還記得上文提到的have嗎? 其實(shí),這個(gè)和include是有區(qū)別的。 一般而言,have通常是和keys進(jìn)行搭配的.

expect({first:1,second:2}).to.have.any.keys("first");
//等價(jià)于
expect({first:1,second:2}).to.include.keys("first");

另外,have本身自帶all的效果,所以感覺"all"通常是和include一起搭配.

expect({first:1,second:2}).to.have.keys("first","second");
//等價(jià)于
expect({first:1,second:2}).to.have.all.keys("first","second");
//等價(jià)于
expect({first:1,second:2}).to.include.all.keys("first","second");
satisfy

這個(gè)應(yīng)該可以算是一個(gè)萬(wàn)能assertion. 他的參數(shù)是一個(gè)函數(shù),接受的參數(shù)就是expect里面的內(nèi)容。 而且該函數(shù)的返回值必須是Boolean. 如果你的返回值沒有的話,那么該case是不會(huì)通過(guò)的。

expect({first:1,second:2}).to.satisfy(function(obj){
            return obj.first===1;
        }); 
        //pass

雖然是萬(wàn)能的,但是極力不推薦使用,因?yàn)槭窃谑翘糜昧?,而造成的problem就是你的測(cè)試用例不清晰,沒有很好的可讀性。要知道斷言庫(kù)的出現(xiàn)就是讓你的測(cè)試用例能夠像文章一樣具有良好的可讀性.

match

這個(gè)方法其實(shí)和string.match是比較類似的。他們都是用來(lái)檢測(cè)字符串類型,是否滿足正則的測(cè)試。

expect("good").to.match(/(oo){1}/);
//pass
change

用來(lái)表征一個(gè)對(duì)象的值是否被一個(gè)函數(shù)所改變.

get to the point

//測(cè)試對(duì)象
var test2 = {
    bar:1
}
function changeValue(){
    test2.bar=2;
}
//測(cè)試用例
expect(changeValue).to.change(test2,"bar");

事實(shí)上,這個(gè)真的沒有什么卵用。用的頻率還是蠻低的。
Okkkkay~
在斷言中還有最重要的一部分,關(guān)于number的判斷.
常用的number判斷有:

above(alias: gt)
below(alias: lt)
least(alias: gte)
most(alias: lte)
within
above

above等價(jià)于greater than(>=). 但是above能更好的表達(dá)語(yǔ)義,所以這里就使用above.

expect(2).to.above(1);
below

同理below和above類似. below等價(jià)于less than(<=)

expect(2).to.not.below(1);
expect(2).to.below(3);
least

在中文意譯就為至少為多少~ 翻譯為數(shù)學(xué)語(yǔ)言就是 (>=) . 這里,我們需要明確一個(gè)概念,即,測(cè)試用例應(yīng)該給你最直觀的感受, 我們的用例是給normal people看的,而不是特指針對(duì)于數(shù)學(xué)家,或者程序員看的。
使用最佳語(yǔ)義化的表達(dá)就是最重要的.

expect(num).to.least(1); //翻譯一遍就是: num至少為1
most

和least相似。我這里就不舉例論證了。

expect(num).to.most(12); //num最多為12
within

標(biāo)識(shí)一個(gè)數(shù)的range. 相當(dāng)于,數(shù)學(xué)上的 "[num1,num2]". 判斷你的expect是否在這個(gè)區(qū)間內(nèi)。

expect(1).to.within(1,2); //pass

關(guān)于Number這一塊內(nèi)容我們差不多梳理完了。
是不是很枯燥呀~
恩~ 我也這么覺得
下面,我們?cè)賮?lái)看一點(diǎn)枯燥的東西唄。 破罐子破摔
類型判斷
要知道,在js中,類型判斷是最奇葩的一個(gè)。 針對(duì)于類型js已經(jīng)出啦3個(gè)方法來(lái)判斷》 instanceof typeof constructor. 在各種庫(kù)里,也出現(xiàn)了想isArray,isBoolean,isArrayLike等語(yǔ)義API判斷。 在斷言庫(kù)里,類型判斷也是必不可少的一部分。

instanceof
ok
false
true
null
undefined
exist
empty
instanceof

和constructor類型判斷類似。 用來(lái)判斷一個(gè)對(duì)象的原來(lái)構(gòu)造函數(shù)是誰(shuí)。

function changeValue(){}
var test1 = new changeValue();
describe("Test",function(){
    it("test",()=>{
        expect(test1).to.be.instanceof(changeValue);
    })
})
ok/true/exist

上述3個(gè)語(yǔ)法的關(guān)系應(yīng)該是:exist>ok>true.
由于3者類似,這里就一起說(shuō)明了。
exist就是用來(lái)判斷一個(gè)值是否存在,即,既不是null也不是undefined.
而,ok是用來(lái)判斷一個(gè)值是否ok(別打我~). 即,該值既不是null,也不是undefined,更不是false
true就很簡(jiǎn)單,只有true才能pass. 相當(dāng)于"==="的效果.
詳看demo:

//exist->pass
expect("exist").to.exist;
expect(null).to.not.exist;
expect(undefined).to.not.exist;
expect(false).to.exist;
//ok->pass
expect("exist").to.be.ok;
expect(null).to.not.be.ok;
expect(undefined).to.not.be.ok;
expect(false).to.not.be.ok; //對(duì)于上面的exist
//true->pass
expect(true).to.be.true;
expect(1).to.not.be.true;
false/null/undefined/empty

這些都是判斷一個(gè)內(nèi)容是否不滿足時(shí)而造出來(lái)語(yǔ)法.
看字面形式可以知道,他們分別對(duì)應(yīng)于自己的類型。
false->false
null->null
undefined->undefined
而,empty則是判斷expect的length是否為0. 當(dāng)然針對(duì)于沒有l(wèi)ength屬性的類型。測(cè)試用例應(yīng)該會(huì)die。

expect("").to.be.empty;
expect(12).to.not.be.empty;

到這里,expect的斷言庫(kù),差不多就這些了。 如果大家還有種想要學(xué)習(xí)的沖動(dòng),可以去mocha官網(wǎng)上學(xué)習(xí)(認(rèn)真臉)

BDD額外語(yǔ)法

上篇介紹了describe的一些基本語(yǔ)法,但是好像還是紕漏了一些,比較高級(jí)的API。
一個(gè)為only.一個(gè)為skip.還有一個(gè)為done

only

only方法表示在一個(gè)block內(nèi),只運(yùn)行該用例的測(cè)試。它通常在你滿屏輸出錯(cuò)誤的時(shí)候,進(jìn)行分開修改bug而使用的. 可以在it或者describe上面使用

describe("Test",function(){
    it.only("test",()=>{
        expect(1).to.equal(1);
    });
    it("it will output error",function(){
        expect(2).to.equal(3);
    })
})
//在命令行測(cè)試會(huì)直接pass。 因?yàn)榈诙€(gè)測(cè)試用例并沒有執(zhí)行
skip

該方法,用來(lái)跳過(guò)某個(gè)測(cè)試用例。 同樣在正常情況下,我們不會(huì)使用這個(gè)API。 它的使用情況依然是,調(diào)試你在一個(gè)Block里,寫出很多個(gè)測(cè)試時(shí),才會(huì)使用.

describe("Test",function(){
    it("test",()=>{
        expect(1).to.equal(1);
    });
    it.skip("it will output error",function(){
        expect(2).to.equal(3);
    })
})
//第一個(gè)會(huì)提示pass
//第二個(gè)會(huì)提示pending
done

這個(gè)應(yīng)該是為js量身打造的.因?yàn)閖s本身就是一門異步語(yǔ)言,而mocha無(wú)法污染異步的API,所以這個(gè)done就是給我們手動(dòng)去檢測(cè)異步結(jié)束而設(shè)立的。
來(lái)個(gè)栗子:

//沒有異步效果,結(jié)果會(huì)直接輸出I"m testing,而I"ve finished test卻沒有效果
describe("Test",function(){
    it("test",()=>{
        console.log("I"m testing")
        setTimeout(function(){
            console.log("I"ve finished test");
        },200);
    });
})
//這里我們需要加上一個(gè)異步的flag--done
describe("Test",function(){
    it("test",(done)=>{  //這里加上一個(gè)done的參數(shù),表示這是個(gè)異步的測(cè)試用例
        console.log("I"m testing")
        setTimeout(function(){
            console.log("I"ve finished test");
            done();  //這里手動(dòng)告訴mocha我已經(jīng)測(cè)試完了
        },200);
    });
});
輸出的結(jié)果為:
//I"m testing
//I"ve finished test

而,大部分時(shí)候,異步測(cè)試并不是去測(cè)試setTimeout(are u **?). 最主要測(cè)試異步的應(yīng)該是Promise或者是$.Deferred。不過(guò)es6最近風(fēng)行,我們一樣以Promise作為例子,Deferred的原理和Promise是一樣的.

異步測(cè)試Promise

測(cè)試Promise的時(shí)候,我們當(dāng)然可以使用上述的done方法來(lái)mark一下.

describe("Test",function(){
    before(function(){
        console.log("I"m testing");
    })
    it("test",(done)=>{
        "use strict";
        new Promise(function(resolve,reject){
            setTimeout(()=>{
                resolve("ok");
            }, 200)
        })
        .then(function(){
            console.log("I"ve finished the test");
            done();
        })
    });
});
//正常情況會(huì)輸出: 標(biāo)識(shí)成功
// I"m testing
//I"ve finished the test

但是需要注意的是,如果你的異步執(zhí)行時(shí)間過(guò)長(zhǎng),mocha是不會(huì)wait u的。 mocha默認(rèn)的最低時(shí)間是2s。所以,如果你的異步時(shí)間超出了。像這樣:

    new Promise(function(resolve,reject){
            setTimeout(()=>{
                resolve("ok");
            }, 2000)
        })
        .then(function(){
            console.log("I"ve finished the test");
            done();
        })

他會(huì)直接爆出這樣的錯(cuò)誤.

 Error: timeout of 2000ms exceeded

當(dāng)然,如果你想改變他的默認(rèn)值設(shè)置也可以。
想這樣設(shè)置就over了

mocha -t 10000

或者直接測(cè)試用例中多帶帶設(shè)置:

describe("Test",function(){
    this.timeout(100);
    before(function(){
        console.log("I"m testing");
    });
    it("test",(done)=>{
        "use strict";
        new Promise(function(resolve,reject){
            setTimeout(()=>{
                resolve("ok");
            }, 2000)
        })
        .then(function(){
            console.log("I"ve finished the test");
            done();
        })
    });
});
//由于你的時(shí)間設(shè)置過(guò)短,所以會(huì)出現(xiàn)上述一樣的錯(cuò)誤

這里的this.timeout只能影響到,當(dāng)前的測(cè)試套件。 在下一個(gè)測(cè)試套件內(nèi),還是依照默認(rèn)值2000ms。

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://m.hztianpu.com/yun/8712.html

相關(guān)文章

  • 探知JS測(cè)試(1)

    摘要:?jiǎn)卧獪y(cè)試這是測(cè)試類型的一種,所謂的單元即,由一些函數(shù)組成能完成某項(xiàng)功能的模塊。單元測(cè)試的過(guò)程想好測(cè)試用例動(dòng)手寫測(cè)試查看測(cè)試結(jié)果,通過(guò)則否則應(yīng)該進(jìn)行測(cè)試模式想說(shuō)一下,測(cè)試模式和單元測(cè)試的區(qū)別。測(cè)試模式包括單元測(cè)試通常測(cè)試模式有和模式。 有一定水平的js童鞋,應(yīng)該會(huì)經(jīng)??吹揭恍?,在介紹項(xiàng)目的時(shí)候,會(huì)不由自主說(shuō)道測(cè)試。 比如,單元測(cè)試,函數(shù)測(cè)試,或是TDD,BDD等測(cè)試模式。沒錯(cuò),這也是...

    xingpingz 評(píng)論0 收藏0
  • 探知JS測(cè)試(1)

    摘要:?jiǎn)卧獪y(cè)試這是測(cè)試類型的一種,所謂的單元即,由一些函數(shù)組成能完成某項(xiàng)功能的模塊。單元測(cè)試的過(guò)程想好測(cè)試用例動(dòng)手寫測(cè)試查看測(cè)試結(jié)果,通過(guò)則否則應(yīng)該進(jìn)行測(cè)試模式想說(shuō)一下,測(cè)試模式和單元測(cè)試的區(qū)別。測(cè)試模式包括單元測(cè)試通常測(cè)試模式有和模式。 有一定水平的js童鞋,應(yīng)該會(huì)經(jīng)??吹揭恍?,在介紹項(xiàng)目的時(shí)候,會(huì)不由自主說(shuō)道測(cè)試。 比如,單元測(cè)試,函數(shù)測(cè)試,或是TDD,BDD等測(cè)試模式。沒錯(cuò),這也是...

    bladefury 評(píng)論0 收藏0
  • 探知js測(cè)試(3)

    摘要:模塊測(cè)試模塊語(yǔ)法我這里提及一點(diǎn)?;竟こ棠夸浺粋€(gè)良好的工程目錄,能夠幫助你測(cè)試成本降到最低。這一塊算是獨(dú)立于單元測(cè)試的。 前面兩篇已經(jīng)把,js測(cè)試的模式,框架,斷言庫(kù)基本介紹了一遍。這里,我們要上升到整體測(cè)試架構(gòu)上來(lái).首先,單元測(cè)試的對(duì)象是模塊,這里我們就要將自己測(cè)試目標(biāo)調(diào)整到對(duì)模塊測(cè)試上來(lái)。所以,這里我們需要使用CommonJS或者es6的模塊的寫法了。另外需要了解,mocha框架測(cè)...

    陳江龍 評(píng)論0 收藏0
  • 探知js測(cè)試(3)

    摘要:模塊測(cè)試模塊語(yǔ)法我這里提及一點(diǎn)?;竟こ棠夸浺粋€(gè)良好的工程目錄,能夠幫助你測(cè)試成本降到最低。這一塊算是獨(dú)立于單元測(cè)試的。 前面兩篇已經(jīng)把,js測(cè)試的模式,框架,斷言庫(kù)基本介紹了一遍。這里,我們要上升到整體測(cè)試架構(gòu)上來(lái).首先,單元測(cè)試的對(duì)象是模塊,這里我們就要將自己測(cè)試目標(biāo)調(diào)整到對(duì)模塊測(cè)試上來(lái)。所以,這里我們需要使用CommonJS或者es6的模塊的寫法了。另外需要了解,mocha框架測(cè)...

    pakolagij 評(píng)論0 收藏0
  • 探知JS測(cè)試(2)

    摘要:針對(duì)于類型已經(jīng)出啦個(gè)方法來(lái)判斷在各種庫(kù)里,也出現(xiàn)了想等語(yǔ)義判斷。在斷言庫(kù)里,類型判斷也是必不可少的一部分。測(cè)試用例應(yīng)該會(huì)。在下一個(gè)測(cè)試套件內(nèi),還是依照默認(rèn)值。 前一篇文章,我們已經(jīng)簡(jiǎn)單的闡述了BDD,TDD以及mocha測(cè)試框架,chai斷言庫(kù). 這里我們將進(jìn)一步深入,比較全部的了解測(cè)試的API。前文,我們已經(jīng)知道了,BDD本身可以比擬為文章的骨架,而chai斷言庫(kù)就是骨架里面的血管和...

    TZLLOG 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

閱讀需要支付1元查看
<