資訊專欄INFORMATION COLUMN
摘要：單元測試之?dāng)嘌宰鳛榍岸碎_發(fā)，很少去自己寫單元測試。對于單元測試的了解也很少，自學(xué)了一點(diǎn)關(guān)于單元測試斷言的知識，有了一些自己的個(gè)人理解，記錄下來，方便下次使用時(shí)查閱。是被測試值的類型，也就是斷言的期望值。其中主要適用于行為驅(qū)動測試。
單元測試之?dāng)嘌?/b>
作為前端開發(fā)，很少去自己寫單元測試。對于單元測試的了解也很少，自學(xué)了一點(diǎn)關(guān)于單元測試斷言的知識，有了一些自己的個(gè)人理解，記錄下來，方便下次使用時(shí)查閱。什么是斷言
當(dāng)你對類，模塊或者方法的可以接受的輸入和輸出有著很明確的定義和認(rèn)識，當(dāng)程序的輸出結(jié)果和輸入不匹配時(shí)，
你想讓程序有一個(gè)明確的返回。比如：我明確地知道1+1=2,我現(xiàn)在就想知道我輸入1+1會不會得到2。如果不是程序返回一個(gè)錯(cuò)誤。這時(shí)候我們通常會使用到斷言。
斷言就是專門用來驗(yàn)證輸出和期望是否一致的一個(gè)工具。在內(nèi)容的實(shí)現(xiàn)上，它是通過比較一個(gè)實(shí)際值actual和一個(gè)期望值expected來實(shí)現(xiàn)的。下面介紹一個(gè)使用較為廣泛的斷言庫chai.js
chai.js斷言庫安裝和導(dǎo)入
npm i chai import chai from "chai" let expect = chai.expect;
使用
let foo = "bar";
expect(foo).to.equal("bar");
chai的使用是類似于鏈?zhǔn)秸{(diào)用的形式。以expect(foo).to.be.a("string");為例，
通過.我么你可以把這個(gè)鏈?zhǔn)椒譃閹讉€(gè)部分：
expect(foo)
to
be
a("string")
我們逐步來理解這幾個(gè)部分：
expect(foo)：是你要斷言的對象，翻譯過來就是我希望某某某
to：虛詞，單純作為語言鏈提供以期提高斷言的可讀性，它本身并不具有斷言功能。
be:同to一樣，是語言鏈調(diào)用提高可讀性。
a(string)：a(type)是一個(gè)斷言，用來判斷測試紙的類型。type是被測試值的類型，也就是斷言的期望值。
那么根據(jù)上面的分析，我們可以知道實(shí)現(xiàn)一個(gè)斷言需要這幾個(gè)部分：
要斷言的對象
不具備斷言功能的斷言詞
具備斷言功能的斷言詞
以及期望結(jié)果
要斷言的對象和期望結(jié)果都是需要根據(jù)實(shí)際輸入和輸出進(jìn)行設(shè)置的。因此我們主要是講解斷言詞。
不具備斷言功能的斷言詞to
be
been
is
that
which
and
has
have
with
at
of
same
but
does
still
這些斷言詞其實(shí)沒有意義，你把它去掉也不受到影響。比如：
expect(foo).to.equal("bar");
expect(foo).equal("bar");
上面兩個(gè)斷言能夠?qū)崿F(xiàn)相同的功能。也就是說這些詞語使不使用沒什么影響。
接下來說一下具備斷言功能的斷言詞。
equal
equal是一個(gè)基本上萬能的斷言詞，絕大多數(shù)的斷言都可以轉(zhuǎn)換成使用equal來實(shí)現(xiàn)。
比如判斷變量長度是否為3，我們可以使用lengthOf,同樣可以使用equal實(shí)現(xiàn)
expect(foo).have.lengthOf(3); expect(foo.length).equal(3)；
比如判斷數(shù)據(jù)類型：我們既可以使用a，同樣可以使用equal實(shí)現(xiàn)
expect(foo).to.be.a("string");
expect(typeof foo).to.equal("string");
.deep
deep主要是用來遞歸比較對象的鍵值對，而不是比較對象本身。通常配合equal和property進(jìn)行使用。
比如：
expect([1,2]).equal([1,2]) // 斷言不通過
上面的斷言無法通過，因?yàn)橐妙愋偷谋容^的是對象。接下來我們看使用deep
expect([1,2]).deep.equal([1,2]) // 斷言通過
也就是說如果是數(shù)組，對象等引用類型時(shí)，要比較里面的值需要使用deep。
通過使用equal和deep我們基本上能夠?qū)崿F(xiàn)絕大多數(shù)的斷言。更多的關(guān)于斷言
可以參考官網(wǎng)
目前只是介紹了expect的使用，其實(shí)chai.js還有assert和should兩種斷言方式。
其中expect主要適用于行為驅(qū)動測試(Behavior Driven Development.BDD)。其他兩種斷言方式，以后用到了再進(jìn)行介紹。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/106567.html
摘要：四結(jié)論本章幾乎所有的內(nèi)容在單元測試經(jīng)常使用到的東西特別是異步部分，三種不同異步方式并非共存的，而是需要根據(jù)具體業(yè)務(wù)而采用。否則，你會發(fā)現(xiàn)真難寫單元測試。自此，我們算是為寫單元測試打下了基礎(chǔ)。 以下是我假定那些極少或壓根沒寫單元測試的人準(zhǔn)備的，因此，會白話解釋諸多概念性問題，同時(shí)會結(jié)合 Jasmine 與之對應(yīng)的方法進(jìn)行講解。 一、概念 Test Suite 測試套件，哪怕一個(gè)簡單的類，...
摘要：寫好的單元測試，對開發(fā)速度項(xiàng)目維護(hù)有莫大的幫助。我認(rèn)為單元測試的上下文存在于敏捷中。接下來一小節(jié)，就可以正式進(jìn)入如何做的環(huán)節(jié)了如何寫好單元測試。前面說到，我們對單元測試寄予 寫好的單元測試，對開發(fā)速度、項(xiàng)目維護(hù)有莫大的幫助。前端的測試工具一直推陳出新，而測試的核心、原則卻少有變化。與產(chǎn)品代碼一并交付可靠的測試代碼，是每個(gè)專業(yè)開發(fā)者應(yīng)該不斷靠近的一個(gè)理想之地。本文就圍繞測試講講，為什么我...
閱讀 1240·2021-11-23 10:10
閱讀 1644·2021-09-30 09:47
閱讀 981·2021-09-27 14:02
閱讀 3042·2019-08-30 15:45
閱讀 3083·2019-08-30 14:11
閱讀 3679·2019-08-29 14:05
閱讀 1879·2019-08-29 13:51
閱讀 2265·2019-08-29 11:33
