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組織函數
assert(value[, message])
assert.ok() 的別號。
assert.deepEqual(actual, expected[, message]) 已燒毀
附：assert.deepStrictEqual() 的別號。
deepStrictEqual
assert.deepStrictEqual(actual, expected[, message])
測試 actual 參數與 expected 參數是不是深度相稱。 深度相稱意味着子對象中可羅列的本身屬性也會按以下劃定規矩遞歸地比較。
assert.deepStrictEqual({a:1}, {a:1}); //如許的測試是能夠經由過程的
注重：劇本中這倆個是不相對相稱的
doesNotReject
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 毛病。 以上兩種狀況都邑跳過毛病處理函數。
doesNotThrow
assert.doesNotThrow(block, error)
斷言 block 函數不會拋出毛病。
當 assert.doesNotThrow() 被挪用時，它會馬上挪用 block 函數。
假如拋出毛病且毛病範例與 error 參數指定的雷同，則拋出 AssertionError。 假如毛病範例不雷同，或 error 參數為 undefined，則拋出毛病。
assert.equal(actual, expected[, message]) 已燒毀
附：assert.strictEqual() 的別號。
fail
assert.fail([message])
拋出 AssertionError，並帶上供應的毛病信息或默許的毛病信息。 假如 message 參數是 Error 的實例，則會拋出它而不是 AssertionError。
assert.fail(actual, expected[, message[, operator[, stackStartFunction]]]) 已燒毀
附：運用 assert.fail([message]) 替代。
ifError
assert.ifError(value)
假如 value 不為 undefined 或 null，則拋出 value。 可用於測試回調函數的 error 參數。 客棧蹤影會包含傳入 ifError() 的毛病的一切幀，包含潛伏的 ifError() 本身新增的幀。
assert.notDeepEqual(actual, expected[, message]) 已燒毀
附：運用 assert.notDeepStrictEqual() 替代。
notDeepStrictEqual
assert.notDeepStrictEqual(actual, expected[, message])
測試 actual 參數與 expected 參數是不是不深度全等。 與 assert.deepStrictEqual() 相反。
附：assert.notStrictEqual() 的別號。
assert.notEqual(actual, expected[, message]) 已燒毀
附：運用 assert.notStrictEqual() 替代。
notStrictEqual
assert.notStrictEqual(actual, expected[, message])
運用 SameValue 比較法測試 actual 參數與 expected 參數是不是不全等。
ok
assert.ok(value[, message])
測試 value 是不是為真值。 相當於 assert.equal(!!value, true, message)。
rejects
assert.rejects(block, error)
守候 block 的 promise 完成，假如 block 是一個函數，則馬上挪用該函數並守候返回的 promise 完成，然後搜檢 promise 是不是被 reject。
假如 block 是一個函數且同步地拋出一個毛病，則 assert.rejects() 會返回一個被 reject 的 Promise 並傳入該毛病。 假如該函數沒有返回一個 promise，則 assert.rejects() 會返回一個被 reject 的 Promise 並傳入 ERR_INVALID_RETURN_VALUE 毛病。 以上兩種狀況都邑跳過毛病處理函數。
strictEqual
assert.strictEqual(actual, expected[, message])
運用 SameValue 比較法測試 actual 參數與 expected 參數是不是全等。
throws
assert.throws(block, error)
斷言 block 函數會拋出毛病。
至此，斷言模塊一切的 api 我們都清晰了，固然 node 官網關於Assert 模塊另有更細緻的內容。
