摘要:類的一個子類,表明斷言的失敗??捎糜跍y試回調函數的參數。使用比較法測試參數與參數是否不全等。等待的完成,如果是一個函數,則立即調用該函數并等待返回的完成,然后檢查是否被。
FEAT
FrontEnd Automates Test 前端全自動化測試
序章文章開頭先引一個知乎上的問答:如何進行前端自動化測試?
我相信做過前端的朋友都有這個疑問。希望這篇文章里你能看到一些別人的測試方法,幫助你更好的進行測試工作;
很尷尬的是,在此之前我的開發測試也都不會有單元測試而都是人肉測試,對不起自己 ??;
為了以后能夠更好的進行測試工作,記錄自己測試學習的過程,希望能幫自己也能幫到別人。
做測試,應該從哪里開始切入呢 做測試的倆個要素程序:我們往常寫的代碼
測試用例:測試你的代碼的輸入輸出是否符合預期
一個簡單的測試假如有這樣一個倆數相加的程序功能:
function add(a, b){ return a+b }
我們現在要對這個倆數相加的程序功能進行測試,來測試這個 add 方法的輸入輸出是否符合我們的預期,那就要去寫測試用例去測試。
那么我們的測試用例怎么寫呢方式一:你可能這么寫
5 === add(2, 3) // 測試用例(1) (1.7976931348623157e+308 * 2) !== add(1.7976931348623157e+308, 1.7976931348623157e+308 + 1) // 測試用例(2)
測試用例(1)用預期的 5 和 add 方法輸入 2 和 3 的輸出結果進行比對,是否相等;如果相等,那么 add 方法就通過測試用例,如果不等,就證明我們的 add 方法存在問題。
可以看到測試用例(1)
結果是相等,通過測試
測試用例(2)用預期的 1079654173767686669 和 add 方法輸入 1.7976931348623157e+308 和 1.7976931348623157e+308 的輸出結果進行和用例(1)一樣的操作。
可以看到測試用例(2)
結果應該不等, 測試不通過
原因:原來是我們沒有考慮大數相加結果溢出的情況,所以我們的 add 方法是只能在相加的結果不會溢出情況下得到期望的正確結果。
我們就有必要對我們的方法進行改動以適配大數相加,那么每一次這個方法的改動,我們就要執行一次上面的測試用例。這樣我們就能進行我們的而測試工作了。
如果應對簡單的需求這樣的方式顯然夠用了,但是事實上應該是沒人會這么寫測試用例的。
大家會用 nodejs 提供的 assert 模塊或者 shouldjs 這類斷言庫來幫我們做斷言這件事情;而且這些模塊被 node 原生提供支持,后面要在此測試基礎上進行自動化測試,生成測試報告之類的,都非常方便。
下節我們以 assert 模塊為例來改造這個測試用例;這一節我們先做一些準備工作,要寫測試用例,會用到斷言,那么我們這節就先看看斷言的相關內容,以 node 的 Assert 模塊為例:
Assert 模塊assert 模塊提供了斷言測試的函數,用于測試不變式。
assert.AssertionError 類Error 的一個子類,表明斷言的失敗。 assert 模塊拋出的所有錯誤都是 AssertionError 類的實例。
這是我們寫測試用例,執行測試,調試測試過程最常見到的一個類,指示遇到斷言失敗。
assert(value[, message])
assert.ok() 的別名。
assert.deepEqual(actual, expected[, message]) 已廢棄附:assert.deepStrictEqual() 的別名。
deepStrictEqualassert.deepStrictEqual(actual, expected[, message])
測試 actual 參數與 expected 參數是否深度相等。 深度相等意味著子對象中可枚舉的自身屬性也會按以下規則遞歸地比較。
assert.deepStrictEqual({a:1}, {a:1}); //這樣的測試是可以通過的
注意:腳本中這倆個是不絕對相等的
assert.doesNotReject(block, error)
該函數相當于 assert.doesNotThrow(),除了需要等待完成的異步特性。
等待 block 的 promise 完成,如果 block 是一個函數,則立即調用該函數并等待返回的 promise 完成,然后檢查 promise 是否被 reject。
如果 block 是一個函數且同步地拋出一個錯誤,則 assert.doesNotReject() 會返回一個被 reject 的 Promise 并傳入該錯誤。 如果該函數沒有返回一個 promise,則 assert.doesNotReject() 會返回一個被 reject 的 Promise 并傳入 ERR_INVALID_RETURN_VALUE 錯誤。 以上兩種情況都會跳過錯誤處理函數。
assert.doesNotThrow(block, error)
斷言 block 函數不會拋出錯誤。
當 assert.doesNotThrow() 被調用時,它會立即調用 block 函數。
如果拋出錯誤且錯誤類型與 error 參數指定的相同,則拋出 AssertionError。 如果錯誤類型不相同,或 error 參數為 undefined,則拋出錯誤。
附:assert.strictEqual() 的別名。
failassert.fail([message])
拋出 AssertionError,并帶上提供的錯誤信息或默認的錯誤信息。 如果 message 參數是 Error 的實例,則會拋出它而不是 AssertionError。
assert.fail(actual, expected[, message[, operator[, stackStartFunction]]]) 已廢棄附:使用 assert.fail([message]) 代替。
ifErrorassert.ifError(value)
如果 value 不為 undefined 或 null,則拋出 value。 可用于測試回調函數的 error 參數。 堆棧蹤跡會包含傳入 ifError() 的錯誤的所有幀,包括潛在的 ifError() 自身新增的幀。
assert.notDeepEqual(actual, expected[, message]) 已廢棄附:使用 assert.notDeepStrictEqual() 代替。
notDeepStrictEqualassert.notDeepStrictEqual(actual, expected[, message])
測試 actual 參數與 expected 參數是否不深度全等。 與 assert.deepStrictEqual() 相反。
附:assert.notStrictEqual() 的別名。
附:使用 assert.notStrictEqual() 代替。
notStrictEqualassert.notStrictEqual(actual, expected[, message])
使用 SameValue 比較法測試 actual 參數與 expected 參數是否不全等。
okassert.ok(value[, message])
測試 value 是否為真值。 相當于 assert.equal(!!value, true, message)。
rejectsassert.rejects(block, error)
等待 block 的 promise 完成,如果 block 是一個函數,則立即調用該函數并等待返回的 promise 完成,然后檢查 promise 是否被 reject。
如果 block 是一個函數且同步地拋出一個錯誤,則 assert.rejects() 會返回一個被 reject 的 Promise 并傳入該錯誤。 如果該函數沒有返回一個 promise,則 assert.rejects() 會返回一個被 reject 的 Promise 并傳入 ERR_INVALID_RETURN_VALUE 錯誤。 以上兩種情況都會跳過錯誤處理函數。
strictEqualassert.strictEqual(actual, expected[, message])
使用 SameValue 比較法測試 actual 參數與 expected 參數是否全等。
throwsassert.throws(block, error)
斷言 block 函數會拋出錯誤。
至此,斷言模塊所有的 api 我們都清楚了,當然 node 官網對于Assert 模塊還有更詳細的內容。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/95629.html
摘要:塊被稱為測試用例,第個參數是實際執行的函數。每當有代碼更新的時候,先獲取對應的源碼,然后一步步根據配置執行,剛涉及到前端測試,以上內容如有錯誤的地方,請不吝指正。 前端測試 說起前端測試,經常會聽到assert,shouldjs,mocha,karma,travis等等,這些是都是分別用來干什么的呢? 為什么需要前端測試 本人目前工作中,其實沒有涉及到前端測試,周圍的人也很少用到過前端...
摘要:測試驅動開發是一種使用自動化單元測試來推動軟件設計并強制依賴關系解耦的技術。使用這種做法的結果是一套全面的單元測試,可隨時運行,以提供軟件可以正常工作的反饋。 showImg(http://ws1.sinaimg.cn/large/005NRne3gy1g2cmxxl7c5j30nc0c8h1p.jpg); 一、幾種概念(稍微了解一下) ATDD: Acceptance Test Dr...
摘要:基本上,測試金字塔描述你應該編寫單元測試集成測試和端到端測試。集成測試要比端到端測試多,單元測試甚至要更多一些。應用程序單元測試編寫單元測試,是為了看看給定的模塊單元是否工作。 本文轉載自:眾成翻譯譯者:網絡埋伏紀事鏈接:http://www.zcfy.cc/article/1754原文:https://blog.risingstack.com/node-hero-node-js-un...
摘要:斷言斷言是什么模塊提供了一組簡單的斷言測試,可用于測試不變量。環境是他們不必設置大量配置的環境,而是開發人員可以編寫代碼并從測試中獲得即時反饋的地方。每當測試時,結果將出現在您的拉取請求中,您的歷史記錄將在其控制面板中提供。 Node assert (斷言) 斷言是什么 assert 模塊提供了一組簡單的斷言測試,可用于測試不變量。 存在嚴格模式(strict)和遺留模式(legacy...
閱讀 894·2021-09-03 10:42
閱讀 1511·2019-08-30 15:56
閱讀 1444·2019-08-29 17:27
閱讀 870·2019-08-29 15:25
閱讀 3156·2019-08-26 18:27
閱讀 2480·2019-08-26 13:41
閱讀 1888·2019-08-26 10:39
閱讀 1570·2019-08-23 18:36