資訊專欄INFORMATION COLUMN
摘要：我已經把學習如何構建自動化跨瀏覽器的的單元測試列在我的年度清單中，但我每一次坐下來真正想要做的時候，我又退卻了。供應商支持許多主流的單元測試框架，包括，，和。
作者：Philip Walton
譯者：Yeaseon
原文鏈接：Learning How to Set Up Automated, Cross-browser JavaScript Unit Testing
譯文僅供個人學習，不用于任何形式商業目的，轉載請注明原作者、文章來源、翻譯作者及鏈接，版權歸原文作者所有。
我們都知道在多個瀏覽器中測試我們的代碼是多么的重要。至少在我們發布第一個項目的時候，我認為我們在網絡開發社區做大部分工作還是相當不錯的。
我們做的不夠好的工作是測試代碼時每一次做出的改變。
我個人對此感到很慚愧。我已經把“學習如何構建自動化、跨瀏覽器的JavaScript的單元測試”列在我的年度to-do清單中，但我每一次坐下來真正想要做的時候，我又退卻了。雖然我肯定這一部分原因是因為我的懶惰，同時我認為這也是由于缺乏良好的可用信息在這個主題上。
有許多工具和框架（例如 Karma）宣稱“要使自動化的JavaScript測試變得簡單”，但以我的經驗看來這些工具引入的復雜性比他們擺脫的復雜性更多。在我的工作經驗中，如果你是一個專家這些工具“能工作”的很好，但對于一個初學者是很糟糕的。我想要真正了解的是這個流程是如何在引擎中工作的，以便在它出現問題的時候（總會出現問題的），我能解決它。
對我來說，充分了解這些是如何工作的最好方法就是嘗試從頭開始重新創建它。所以我決定去構建我自己的測試工具，然后把我的所學分享到社區中。
手工測試流程在我解釋自動化過程之前，我認為最重要的是確保我們都在同一頁面上進行手工測試工作。
畢竟，自動化是關于使用機器來關閉負載的重復部分的現有工作流程。如果你在充分理解手工過程之前嘗試去開始自動化，它也不會像你理解了自動化過程一樣。
在手工過程中，你寫了一個你的測試文件，它可能看起來像是：
var assert = require("assert");
var SomeClass = require("../lib/some-class");
describe("SomeClass", function() {
describe("someMethod", function() {
it("accept thing A and transforms it into thing B",function() {
var sc = new SomeClass();
assert.equal(sc.someMethod("A"), "B");
});
});
});
這個例子用了Mocha和Node.js 資源模塊，但是重要的不是你是用的測試庫或者斷言庫，它可以使任意一個。
在Mocha中運行Node.js，在你終端通過命令行你就能運行這個測試：
mocha test/some-class-test.js
你需要一個帶有
做一些事情，像下面這樣：
在上面的代碼和默認的Mocha模板中唯一不同的是分配給測試結果的變量名，就像Sauce Labs期望的格式一樣叫做window.mochaResults。因為這個新的代碼不會影響正在瀏覽器中運行的手工測試，你不妨就開始使用它作為默認的Mocha模板。
再次強調一點，當Sauce Labs“運行”你的測試時，它并沒有做任何事，它只是單純的訪問一個頁面，等到發現一個window.mochaResults對象，然后記錄下這個結果。
確定你的測試通過還是失敗
StartJS Unit Tests 方法會告訴Sauce Labs去挨個在你指定的瀏覽器/平臺運行測試，但是它不會返回測試的結果。
它返回所有工作隊列中的ID，響應看起來像是這樣的：
{
"js tests": [
"9b6a2d7e6c8d4fd2afeeb0ff7e54e694",
"d38688ec7256497da6966f4523ddee76",
"14054e68ccd344c0bed77a798a9ce1e8",
"dbc54181f7d947458f52201ea5fcb901"
]
}
要確定你測試通過還是失敗，你要調用GetJS Unit Status方法，它接手一個工作隊列并且返回當前每個工作的工作狀態。
這個想法是你要定期調用這個方法，知道所有工作都完成。
request({
url: `https://saucelabs.com/rest/v1/${username}/js-tests/status`,
method: "POST",
auth: {
username: process.env.SAUCE_USERNAME,
password: process.env.SAUCE_ACCESS_KEY
},
json: true,
body: jsTests, // The response.body from the first API call.
}, (err, response) => {
if (err) {
console.error(err);
} else {
console.log(response.body);
}
});
響應的結果看起來像是這樣：
{
"completed": false,
"js tests": [
{
"url": "https://saucelabs.com/jobs/75ac4cadb85e415fae957f7811d778b8",
"platform": [
"Windows 10",
"chrome", "latest"
],
"result": {
"passes": 29,
"tests": 30,
"end": {},
"suites": 7,
"reports": [],
"start": {},
"duration": 97,
"failures": 0,
"pending": 1
},
"id": "1f74a237d5ba4a47b5a42570ae1e7999",
"job_id": "75ac4cadb85e415fae957f7811d778b8"
},
// ... the rest of the jobs
]
}
一旦response.body.complete屬性值為true，就表示你的測試已經運行完成，然后你就可以通過檢查每個工作流程的通過還是失敗。
本地訪問測試我已經解釋過Sauce Labs“運行”你的測試通過訪問一個URL。當然，這意味著這個URL必須是公開在網絡上可訪問的鏈接。
有一個問題就是如果你的測試服務啟動在localhost。
有很多解決這個問題的方案，包括Sauce Connect（官方推薦的一種），這是一個由Sauce Labs創建的代理服務器，在Sauce Labs虛擬機和本地主機之間開啟一個安全連接。
Sauce Labs是處于安全性的考慮被設計的，并且使得外部無法獲得你的代碼。它的缺點就是十分復雜的設置與使用。
如果你的代碼涉及到安全性，它可能值得你去弄清楚Sauce Labs；如果不是的話，有許多相似的方案去更簡單的解決這個問題。
我選擇的方案是ngrok
ngrok
ngrok是一個用于創建安全隧道連接工具。它給你一個公共的URL到web服務器運行在你的本地機器上，確切的是你需要運行測試在Sauce Labs上。
如果你在虛擬機上進行開發或手動測試，你可能已經聽說過ngrok，如果沒有，那你應該去查閱一下了，它是極其有用的工具。
在你的機器上安裝ngrok像是下載二進制文件，然后添加到你的路徑中一樣簡單；如果你將會在Node中使用ngrok，你也需要通過npm安裝它。
npm install ngrok
你可以用下面的代碼以編程方式從Node中開始ngrok進程：
const ngrok = require("ngrok");
ngrok.connect(port, (err, url) => {
if (err) {
console.error(err);
} else {
console.log(`Tests now accessible at: ${url}`);
}
});
只要你有一個公共的URL能訪問你的測試文件，用Sauce Labs跨瀏覽器測試你的本地代碼會變得十分容易。
整合碎片化這篇文章包含了很多主題，給人的印象是自動化的，跨瀏覽器的JavaScript單元測試是復雜的。但情況并非如此。
我從我的角度來看這篇文章-當我試圖去解決這個問題。然后回顧我之前的經驗，真正復雜的是缺少解決整個流程如何工作的有效信息，和怎么樣把所有的整合到一起。
一旦你了解了所有的步驟，它很簡單。總結：
最初的手工流程
寫一個測試然后創建一個單一的HTML頁面去運行它。
在本地的一個或者兩個瀏覽器中運行這個測試，確保它能工作。
增加自動化流程
創建一個開源的Sauce Labs賬號，獲得一個用戶名和訪問權限。
更新你的測試頁面源碼，以便Sauce Labs能通過JavaScript全局變量讀取測試結果。
用ngrok給你的本地測試頁面創建一個安全隧道，這樣就能在互聯網公開的訪問了。
調用StartJS Unit Tests接口方法列出你想測試的瀏覽器/平臺。
定時調用GetJS Unit Test Status方法知道工作完成。
報告結果。
使測試變得更容易我知道這篇文章開頭我談了很多關于你不需要一個框架來做自動化，跨瀏覽器的JavaScript單元測試，我現在仍然堅信這個。然而，盡管每一步都很簡單，你可能不想在每次都為項目編寫代碼。
我想給我的很多老項目增加自動化測試，所以對我來說打包這些邏輯到我的模塊中是很有意義的。
我推薦你嘗試實現一個你自己的框架，這樣你就可以完全理解它是如何工作的，但如果你沒有時間并且還想快速建立一個測試，我建議你使用我創建的庫Easy Sauce。
Easy SauceEasy Sauce是一個Node包和一個命令行工具，現在我為我想做跨瀏覽器測試的每一個JavaScript項目都使用這個包。
easy-sauce 命令可以設置你的HTML測試文件的路徑（默認是/test/）、開啟本地服務的端口（默認是1337端口）和一系列的瀏覽器/平臺進行測試。easy-sauce將會在Sauce Lab’s selenium cloud運行你的測試，將日志打印在控制臺并通過合適的狀態碼告知你測試是否通過。
npm包使它變得更方便，easy-sauce將會默認在package.json文件中查找配置選項，所以你不必分別的存儲它們。好處是用戶更加明確的知道你的包支持瀏覽器/平臺。
對于easy sauce完整的用法介紹，請查看Github文檔。
最后，我想強調的是我專門建立這個項目來解決我的需要。雖然我認為這個項目對于很多開發人員都十分有用，但我沒有計劃把它變成一個功能齊全的測試解決方案。
結語在這篇文章的開始，我寫下了一系列的需求。在Easy Sauce的幫助下，我正努力的在任何項目中滿足這些需求。
如果你還沒有為你的項目做自動化、跨瀏覽器的JavaScript單元測試，我鼓勵你給Easy Sauce一個嘗試的機會。即使你不想用Easy Sauce，你至少應該了解你自己的需求或更好地了解現有的工具。
Happy testing!
如果你能看到這里，很感謝你的耐心閱讀。
這是我翻譯的第一篇技術文檔，自身水平有限，所以翻譯總有不當與疏漏，如有發現還請您耐心評論指出。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/86390.html
摘要：不論你是在寫瀏覽器端還是后端的，總存在那么一個問題我該使用什么單元測試庫去確保我的代碼如預期的運行呢總是有那么一些流行的框架可供選擇。在中仍然流行，并且擁有來自許多地方性的支持。如果你的測試使用它，直到調用了才能通過。 不論你是在寫瀏覽器端javascript還是后端的nodejs，總存在那么一個問題：我該使用什么單元測試庫去確保我的代碼如預期的運行呢？總是有那么一些流行的框架可供選擇...
摘要：避免脆弱的基類問題。紅牌警告沒有提到上述任何問題。單向數據流意味著模型是單一的事實來源。單向數據流是確定性的，而雙向綁定可能導致更難以遵循和理解的副作用。原文地址 1. 你能說出兩種對 JavaScript 應用開發者而言的編程范式嗎？ 希望聽到： 2. 什么是函數編程？ 希望聽到： 3. 類繼承和原型繼承的不同？ 希望聽到 4. 函數式編程和面向對象編程的優缺點？ ...
摘要：首先安裝單元測試環境使用模塊來模擬定義的模型。根據刪除這是單元測試的最后一小節。需要根據需求和單元測試用例來編寫應用邏輯，使我們的程序更加穩定。我們會運行自動測試用例，一直重構，直到所有單元測試都通過。 本文轉載自：眾成翻譯譯者：文藺鏈接：http://www.zcfy.cc/article/746原文：https://semaphoreci.com/community/tutoria...
摘要：首先安裝單元測試環境使用模塊來模擬定義的模型。根據刪除這是單元測試的最后一小節。需要根據需求和單元測試用例來編寫應用邏輯，使我們的程序更加穩定。我們會運行自動測試用例，一直重構，直到所有單元測試都通過。 本文轉載自：眾成翻譯譯者：文藺鏈接：http://www.zcfy.cc/article/746原文：https://semaphoreci.com/community/tutoria...
閱讀 3022·2021-09-22 14:59
閱讀 1863·2021-09-22 10:02
閱讀 2107·2021-09-04 16:48
閱讀 2259·2019-08-30 15:53
閱讀 2964·2019-08-30 11:27
閱讀 3401·2019-08-29 18:35
閱讀 959·2019-08-29 17:07
閱讀 2668·2019-08-29 13:27
