資訊專欄INFORMATION COLUMN
摘要：本文只討論單測的范疇，對集成測試有興趣的話，可以看下的集成測試代碼。前端單測現狀測試本質上就是假定一個輸入，然后判斷得到預期的輸出。
原文發于我的博客：https://github.com/hwen/blogS...
要不要寫單測？關于這個 cnode 上就有個很有意思的討論
做個調查，你的 Node 應用有寫單測嗎？
看完這個應該會有結論？如果沒有，就回帖跟別人探討下~
測試測試有分為
單元測試（單測）
集成測試
系統測試
主要區別是單測傾向于測試模塊內部運行邏輯及功能，集成測試傾向于模塊間互相組合跟調用的測試。
系統測試（當然你要說，還有自動化測試）是對整個系統的測試，主要由測試人員而非開發人員負責。
本文只討論單測的范疇，對集成測試有興趣的話，可以看下 Vue 的集成測試代碼。
前端單測現狀測試本質上就是假定一個輸入，然后判斷得到預期的輸出。而前端與后端相比，夾雜著瀏覽器 DOM 操作，異步請求，
瀏覽器兼容性等方面的。要我來說，比后端寫單測要麻煩多了。。。
不過現在前端的單測已經發展得比較完善了，已經有一套比較完整的工具鏈，來完成各種需求。
單測工具鏈 框架目前比較流行的測試框架有：
jasmine： 自帶斷言（assert），mock 功能
mocha：框架不帶斷言和mock功能，需要結合其他工具。mocha 是 tj 大神寫的（tj 就是那個寫了express、koa、n、co、ejs的人。。。）
用得比較多的就上面兩個，還有一些用得比較少的，比如 Qunit、intern
框架的實現原理其實就是檢測內部運行的代碼是否有拋出異常。而斷言庫如果沒有得到預期的輸入時，就會拋出異常，給框架檢測到。
PS.想要學 mocha 和單測寫法，最好的資源就是 express 框架的測試代碼（狼叔推薦，親測很不錯）
斷言庫chai：目前比較流行的斷言庫，支持 TDD（assert），BDD（expect、should）兩種風格
shouldjs：也是 tj 寫的，說實話我比較喜歡這個，但是有坑。。。后面會說到。。。
expectjs：基本是 shouldjs 的縮水版
assert：node 的核心模塊，node 環境可以直接使用
mock 庫sinon.js：只用過這個，其他不大清楚。不過這個是目前最多人用的，基本夠了。支持 spies, stub, fake XMLHttpRequest, Fake server, Fake time，很強大
測試集成工具karma：Google Angular 團隊寫的，功能很強大，有很多插件
buster.js: 這個支持 node 環境，但目前還在 beta 版（2017/11/4，版本0.7）。官網
半小時上手單測(并不是學會，就是這么耿直 _(:з)∠)_，手是誰？？？)
使用的是：karma + mocha + chai + sinon（如果之前沒了解過這幾個，可以邊寫邊看文檔，這樣學會快很多）
完整的例子可以在這里找到：GitHub 項目
建議把項目 clone 下來自己跑一遍，然后可以自己加一些特效（啊，不對，是代碼才對。。。
詳細代碼，及配置見 源碼
it("test dom", () => {
const div = document.getElementById("test")
const content = div.innerHTML
content.should.be.equal("here")
setDivContent()
const after = div.innerHTML
after.should.be.equal("hallo world")
})
測試異步請求
it("test async", done => {
getTopics()
.then(res => {
res.success.should.be.equal(true)
done()
})
.catch(err => {
info(err)
done(err)
})
})
調試技巧
調試技巧之一：善用 only
當你的單元測試越寫越多時，想測試新寫的單測是否正確時，可以用 mocha 的 only
這樣做的好處有二：第一屏蔽其他測試可以使測試速度變得更快，第二屏蔽其他測試，可以在你新寫的測試錯誤時
確定這個錯誤不是被其他測試所影響導致的。
用法
describe.only("something", function() {
// 只會跑包在里面的測試
})
或者
it.only("do do", () => {
// 只會跑這一個測試
})
調試技巧之二：善用 debug
要開啟 debug 的話，先在 karma.conf.js 把 singleRun 改成 false
然后，看圖（懶得打字了 (:з)∠)
生成覆蓋率報告也是相當簡單，不過有個要注意的地方就是
現在前端代碼很多都是經過 webpack，babel 編譯的，生成的代碼會多了很多二外的代碼
要解決這個問題使用babel-plugin-istanbul來替代karma-coverage就可以了
preprocessors: {
"src/**/*.js": ["webpack", "coverage"],
"test/*.test.js": ["webpack"]
}
將 karma-coverage 去掉,變成
preprocessors: {
"src/**/*.js": ["webpack"],
"test/*.test.js": ["webpack"]
}
然后在 webpack 配置添加 istanbul 插件
use: {
loader: "babel-loader",
options: {
plugins: ["istanbul"]
}
}
最后可以生成覆蓋率報告
另外有很多工具可以對生成的覆蓋率報告進行進一步的分析，比如最常見的
你會在 Github 上經常見到的圖標
這個就是利用報告里的lcovonly分析生成的
coverageReporter: {
dir: "test/coverage/",
reporters: [
{ type: "html", subdir: "report-html" },
{ type: "lcovonly", subdir: ".", file: "report-lcovonly.txt" }, // 這里，你可以重命名 file
{ type: "text-summary", subdir: ".", file: "text-summary.txt" }
]
}
一些坑
測試時如果有涉及瀏覽器事件（addEventListener），記得測試完移除掉，不然會對其他的測試造成影響（afterEach -> removeEventListener）
mocha 里使用箭頭函數需要注意，因為箭頭函數的 this 指向是靜態的，所以 this 并不指向 mocha（沒有 mocha 上下文）
上面有說到，如果測試的是經過編譯的代碼，需要進行一些配置，目前的辦法是用babel-plugin-istanbul代替karma-cover來檢測覆蓋率
補充前面有說到，為什么不用 should.js？？
因為如果你用 ES6 的語法寫單測（webpack 編譯），用 import should-sinon 會報錯。。
（是不是因為 tj 大神寫完東西不喜歡維護的習慣導致should.js支持性不好？？？）
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/89692.html
摘要：使用可以快速生成一個項目，其中包含了和以及覆蓋率統計的配置參考一個創建測試腳本的快速方法其他參考資料前端自動化測試概覽測試之使用對項目進行單元測試 showImg(https://segmentfault.com/img/bVbjfXr?w=600&h=317); 前言 測試可以提供快速反饋，根據測試用例覆蓋代碼，從而提升代碼開發效率和質量。根據投入產出價值，通常迭代較快的業務邏輯不做...
摘要：使用可以快速生成一個項目，其中包含了和以及覆蓋率統計的配置參考一個創建測試腳本的快速方法其他參考資料前端自動化測試概覽測試之使用對項目進行單元測試 showImg(https://segmentfault.com/img/bVbjfXr?w=600&h=317); 前言 測試可以提供快速反饋，根據測試用例覆蓋代碼，從而提升代碼開發效率和質量。根據投入產出價值，通常迭代較快的業務邏輯不做...
閱讀 3406·2021-11-25 09:43
閱讀 3464·2021-11-19 09:40
閱讀 2464·2021-10-14 09:48
閱讀 1283·2021-09-09 11:39
閱讀 1920·2019-08-30 15:54
閱讀 2821·2019-08-30 15:44
閱讀 1994·2019-08-29 13:12
閱讀 1543·2019-08-29 12:59
