單元測試骨幹。JS應用程序

花費數小時後，也許>天> ，為您的Web應用程序提供了令人敬畏的新功能的完成，您終於準備好看到它的行動。您將新代碼添加到您的JavaScript基礎，構建發布候選者，並啟動您的瀏覽器，希望驚訝。然後……嗯……新功能可能運行良好，但是您的應用程序中的其他一些關鍵部分 - 在開發新版本時您沒有 touch

的部分 - 變得非常糟糕。現在，您面臨著在幾天工作中進行回溯的挑戰，以弄清楚如何打破現有代碼。快樂的日子絕對不在這裡。 >

>這種情況比我想承認的要多。而且，如果您已經編碼了一段時間，那麼您也可能已經看到了它。但是，請考慮一下使這種情況如此痛苦的原因。這並不是因為我們的新代碼破壞了現有代碼；這是不可避免的。真正的痛苦是，花了很長時間才能注意到破裂。由於我們知道我們的應用程序正在起作用，因此有如此多的發展，因此該錯誤可能隱藏了大量代碼。而且，儘管它似乎有點像在草叢中尋找針頭，但我們別無選擇。 在本文中，我們將真正從JavaScript開發中消除這種情況。不再需要在數小時，數天或幾週的代碼中進行挖掘。我們將採用的原則是一個簡單的原則：在我們創建它後立即找到任何錯誤

。這是正確的;我們將建立一個開發環境和流程，當我們編寫引入錯誤的代碼時立即告訴我們。此外，一旦最初的開發完成，我們將付出的額外努力就不會浪費。在集成環境中，捕獲我們開發錯誤的相同測試代碼將完全重複使用。我們可以輕鬆地將測試納入我們的源代碼管理系統中，在錯誤進入我們的代碼庫之前阻止錯誤。 在以下四個部分中，我們將首先研究JavaScript測試環境所需的工具。然後，我們將考慮一個瑣碎的應用程序，該應用程序足夠簡單，可以理解，但具有實際生產Web應用程序中可能存在的所有功能。最後兩個部分展示了我們如何使用環境在開發過程中測試示例應用程序，並且在整合過程中初始開發完成後。

鑰匙要點

• >強調開發過程中的早期錯誤檢測，以防止在後期階段進行複雜的問題，確保平穩的編碼體驗並最大程度地減少回溯。
• >由於其與瀏覽器和node.js環境的兼容性，將摩卡咖啡作為核心測試框架，從而允許從開發到集成測試的無縫過渡。
納入Chai斷言庫，以增強測試可讀性和靈活性，提供多種樣式（斷言，期望，應）符合不同的開發人員偏好。
• >使用sinon.js創建間諜，存根和模擬，這對於在不影響其操作的情況下測試與外部庫和服務的互動至關重要。
>使用Test'em設置連續測試環境，以自動在代碼更改上運行測試，從而立即提供有關應用程序健康的反饋。 >
• 在開發過程中，專注於為模型，視圖和收集創建詳細的單元測試，以確保每個組件孤立地正確起作用。 通過將單位測試與Node.js調整為命令行執行，以確保應用程序在生產環境中的預期行為，從而平穩地過渡到集成測試。
• 組裝JavaScript測試環境
1. 我們的環境必須支持開發過程中無摩擦，連續測試。 在開發過程中創建的測試必須同樣在集成中。
>
執行環境
對於JavaScript編碼，沒有比現代Web瀏覽器更好的開發環境。無論您的口味是Firebug還是Webkit的開發人員工具，瀏覽器都支持實時檢查和編輯，完整的交互式調試以及復雜的性能分析。 Web瀏覽器非常適合開發，因此我們的測試工具和環境必須與瀏覽器內開發集成。但是，Web瀏覽器對於集成測試並不是那麼好。集成測試通常發生在雲中某個地方的服務器上（或至少在數據中心中的某個地方）。這些系統甚至沒有圖形用戶界面，更不用說現代的Web瀏覽器了。為了有效的集成測試，我們需要簡單的命令行腳本和支持它們的JavaScript執行環境。對於這些要求，選擇的工具是node.js。儘管還有其他命令行JavaScript環境，但沒有一個可以匹配Node.js的寬度和深度。在集成階段，我們的測試工具必須與node.js.

集成。

測試框架
>我們已經確定我們的測試工具必須支持Web瀏覽器和Node.js環境，我們可以縮小選擇的範圍，以選擇核心測試框架。存在許多JavaScript測試框架，但大多數人傾向於瀏覽器測試。通常可以讓他們與node.js一起工作，但通常需要不高的黑客攻擊或調整。摩卡咖啡是一個不遭受此問題的框架，其合理地描述為：>
> Mocha是在節點和瀏覽器上運行的功能豐富的JavaScript測試框架，使異步測試簡單而有趣。

Mocha最初是為Node.js開發的，它也很容易支持Web瀏覽器。通過使用Mocha作為我們的測試框架，我們可以編寫支持開發和集成而無需修改的測試。

>斷言庫

與某些JavaScript測試框架不同，摩卡咖啡是為了最大程度的靈活性而設計的。結果，我們將不得不選擇其他一些作品來完成。特別是，我們需要一個JavaScript斷言庫。為此，我們將依靠Chai主張庫。柴的某種獨特之處在於它支持所有常見的斷言樣式 -

sustert>，>期望， and 應該。代碼。在封面下，它們都是等效的。將測試從一種斷言樣式轉換為另一種主張風格很容易。斷言風格的主要區別在於它們的可讀性。主張樣式的選擇主要取決於您（或您的團隊）認為最可讀性的樣式，哪種風格會產生最可理解的測試。要查看差異，請考慮為以下代碼開發瑣碎的測試：>

>傳統的斷言測試可以寫為：

<span>var sum = 2 + 2;</span>

>
該測試可以完成工作，但是除非您已經習慣了老式的單元測試，否則閱讀和解釋可能有些挑戰。替代斷言風格的使用期望：

assert<span>.equal(sum, 4, "sum should equal 4");</span>

大多數開發人員發現，與斷言風格的測試相比，預期的斷言更容易閱讀和理解。第三個替代方案應該使考試斷言更像是自然語言：

<span>expect(sum).to.equal(4);</span>

> Chai庫支持所有三種主張樣式。在本文中，我們應該堅持。

sum<span>.should.equal(4);</span>

間諜，存根和模擬

>

>大多數Web應用程序，包括我們將在本文中考慮的瑣碎示例，依賴第三方庫和服務。在許多情況下，測試我們的代碼需要觀察甚至控制這些庫和服務。 Sinon.js庫提供了許多用於測試這些交互的工具。這樣的工具分為三個一般類：
間諜
。測試代碼觀察到正在測試的代碼之外的功能的調用。間諜不會干擾這些外部功能的操作；他們只是記錄調用和返回值。
• > stub
。測試代碼供應在測試的代碼之外調用功能。存根代碼不會嘗試複製外部功能；當測試中的代碼訪問外部功能時，它只是防止未解決的錯誤。 >
• 模擬。測試代碼模仿正在測試的代碼之外的功能或服務。使用模擬，測試代碼可以從這些函數或服務中指定返回值，以便可以驗證代碼的響應。 >
• >與sinon.js庫本身一起，我們可以使用Sinon.js主張chai。

  單元測試開發環境

  >我們測試工作台的最終工具是用於單元測試的開發環境。在我們的示例中，我們將使用Test’EM。 Test’em是一個方便的腳本集合，用於設置並運行連續的測試環境。如果我們選擇，我們可以自己編寫腳本並手動管理環境；但是，Toby Ho（Test’em的創建者）整理了一個很棒的軟件包，可以節省我們的麻煩。

  示例應用程序

  要查看我們的測試環境，請考慮一個簡單的應用程序。儘管該應用程序包含了實際應用所需的所有功能，但該應用程序包含了其裸露的必需品。 （該應用程序的完整源代碼可在GitHub上找到。）

  >

  >用戶可以看到他們的毒品列表，他們可以單擊一個複選框以切換任何todo的狀態。

  todos數據庫
  >我們的應用程序從包含托多斯信息的數據庫表開始。這是我們可以用來創建該表的SQL。
  >我們在其中放了一些測試數據後，表可能會看起來。

  <span>var sum = 2 + 2;</span>

  id

  title 完整 1A示例數據庫中的todo項目 2 ANATHONE樣品todo item1 3 yet另一個樣本todo item0 >如表所示，我們的Todos僅包括一個主鍵（ID），標題和一個狀態位，以指示它們是否完成。 一個REST API

  我們的Web應用程序需要訪問此數據庫，因此我們將提供標準的REST接口。 API遵循Ruby慣例，但是任何服務器技術都可以輕鬆實現。特別是：

  get api/todos返回數據庫中所有行的JSON編碼陣列。
  get api/todos/nnn返回todo的json表示，ID等於nnn。
  • > POST API/TODOS使用請求中的JSON編碼的信息在數據庫中添加了新的TODO。
  put api/todos/nnn使用請求中的JSON編碼的信息更新與NNN等於NNN的todo。
  刪除API/TODOS/NNN從數據庫中刪除與NNN等於NNN的TODO。
  • >
  • 如果您不是特別喜歡Ruby，則源代碼包括此API的完整PHP實現。
  • > JavaScript庫
  >我們的適度應用程序足夠簡單，可以在沒有任何庫的純JavaScript中實現，但是我們的計劃要大得多。我們可能會開始較小，但最終該應用程序將具有驚人的功能和令人愉悅的用戶界面。為了準備那天，我們將建立一個可以支持我們最終殺手應用程序的框架：>
  • >用於DOM操作，事件處理和服務器通信的jQuery
  undescore.js用許多難以置信的公用事業來增強核心語言。
  backbone.js以模型和視圖來定義應用程序的結構。
  • >
  html骨架
  >現在，我們知道將包含我們應用程序的組件，我們可以定義支持它的HTML骨架。 （現在）沒有什麼幻想的，只有最小的HTML5文檔，一些JavaScript文件以及一小部分代碼可以啟動。

  >

  在開發過程中進行測試

  <span>var sum = 2 + 2;</span>

  >現在我們已經選擇了我們的工具並指定了該應用程序了，現在該開始開發了。我們的第一個任務是安裝工具。

  >安裝工具

  即使我們將在瀏覽器中開發，我們的測試環境也依賴於node.js。因此，第一步是安裝node.js和Node軟件包管理器（NPM）。 Node.js網站上有針對OS X，Windows，Linux和Sunos的可執行性二進製文件，以及其他操作系統的源代碼。運行安裝程序後，您可以從命令行驗證node.js和npm。

  >我們需要的其他所有內容都可以作為節點軟件包可用。 Node軟件包管理器可以處理其安裝以及任何依賴項。 >

  assert<span>.equal(sum, 4, "sum should equal 4");</span>

  創建項目結構
  此示例的源代碼包括一個完整的項目結構，其中包含以下15個文件：>

  <span>expect(sum).to.equal(4);</span>

  這是每個文件夾和文件所包含的內容：

  > testem.json：test'em的配置文件；我們將很快詳細介紹一下。
  • >
  api/：用於我們的REST API實現的文件夾。
  • api/htaccess：支持我們的REST API的Apache Web服務器的示例配置。
    • api/todos.php：實現REST API的PHP代碼。
    lib/：應用程序本身使用的JavaScript庫和測試框架的文件夾。
  lib/backbone-min.js：backbone.js。
  • 的縮小版本
    lib/chai.js：柴斷言圖書館。
    • >
    > lib/jquery-1.9.0.min.js：jquery的縮小版本。
    lib/sinon-1.5.2.js：sinon.js庫。
    lib/sinon-chai.js：sinon.js chai的主張。
    lib/underscore-min.js：unterscore.js。
    • > mysql/：用於應用程序的mySQL代碼的文件夾。
    > mysql/todos.sql：mysql命令創建應用程序數據庫。 >
  • php-lib/：用於PHP庫的文件夾和應用程序REST API的配置。
    php-lib/dbconfig.inc.inc.php：REST API的PHP數據庫配置
  • > src/：我們的客戶端應用程序代碼的文件夾。
    • > src/app-todos.js：我們的應用程序。
  • >測試/：測試代碼的文件夾。
    • test/app-todos-test.js：我們應用程序的測試代碼。
    >測試/摩卡咖啡：摩卡咖啡的配置選項；我們將在下一部分中查看這一點。
  • • 在開發過程中，我們只對其中三個文件感興趣，即Testem.json，src/app-todos.js和test/app-todos-test.js。
    >配置test’em
    實際開發之前的最後一步是定義Test'EM配置。該配置位於JSON-formatted Testem.json中，它足夠簡單，可以在任何文本編輯器中創建。我們只需指定我們使用的是摩卡咖啡（test'em支持多個框架），然後列出了我們的應用程序和測試代碼所需的JavaScript文件。
  開始開發

  >最後，我們準備好編碼了。在命令外殼中，導航到我們項目的根文件夾並執行命令testem。 Test’em腳本將運行，清除終端窗口，並在右上方給我們一個URL。將該URL複製並粘貼到我們選擇的瀏覽器中，我們已經離開了。

  >
  >一旦我們啟動Web瀏覽器，它將自動執行我們定義的所有測試。由於我們剛剛開始開發，因此我們將沒有任何代碼，也不會有任何測試用例。瀏覽器將向我們指出。

  >

  <span>var sum = 2 + 2;</span>

  我們啟動測試的終端窗口也將為我們提供狀態。

  第一個測試用例

  >本著真正的測試驅動開發的精神，我們將首先在測試/app-todos-test.js文件中編寫第一個測試用例。像任何好的Web應用程序一樣，我們希望最大程度地減少全球名稱空間污染。為此，我們將依靠一個全局變量doApp來包含我們的所有代碼。我們的第一個測試案例將確保存在全局名稱空間變量。

  >

  <span>var sum = 2 + 2;</span>

  如您所見，我們需要一個初步陳述，以告訴Mocha我們正在使用Chai主張。然後，我們可以開始編寫測試。通過慣例，javaScript測試被組織成塊（可以嵌套到子塊中，依此類推）。每個塊以DECRICON（）函數調用開始，以確定我們正在測試的代碼的哪個部分。在這種情況下，我們正在測試總體應用程序，因此這是第一個描述（）的參數。

  >

  在測試塊中，我們通過測試的內容記錄了每個測試用例。這就是IT（）函數的目的。讀取任何測試案例的方法是將描述（）和（）字符串組合到單個語句中。因此，我們的第一個測試案例是

  應用程序為名稱space

  創建一個全局變量

  測試代碼本身在IT（）塊內部。我們的測試案例是

  assert<span>.equal(sum, 4, "sum should equal 4");</span>

  >現在我們有一個完整的測試用例。一旦我們保存文件，test'em便會自動接管。它注意到我們的一個文件已更改，因此它立即重新運行測試。毫不奇怪（由於我們尚未為應用程序編寫任何代碼），我們的第一個測試失敗了。
  終端窗口也會自動更新。
  要進行測試，我們必須創建全局名稱空間變量。我們轉移到srcapp-todos.js文件並添加必要的代碼。 >
  >我們保存文件後，請再次驗證“ EM再次彈出”。我們立即為測試案例獲得更新的結果。

  <span>expect(sum).to.equal(4);</span>

  >
  >退後一會兒，考慮發生了什麼！每當我們更改測試代碼或應用程序時，Test`EM都會立即重新運行我們的整個測試套件。我們要做的就是將Test'Em的瀏覽器或終端窗口保持在屏幕的角落，並且在開發>時，我們可以實時看到代碼的健康狀況。即使引入一個錯誤，我們也會知道，即使該錯誤在代碼的一部分中表現出來，與我們正在工作的位置不同。在我們引入錯誤時，不再需要在數小時，幾天或幾週的新代碼中進行挖掘。

  測試模型

  >隨著我們的開發環境現已完全建立，我們可以開始開發應用程序。由於我們的應用程序顯示了招待員列表，因此最好為這些毒品創建一個模型。該模型將需要跟踪Todo的標題及其狀態。讓我們添加一個單元測試，該測試可以驗證我們可以使用合理默認值創建一個todo。

  >

  <span>var sum = 2 + 2;</span>

  這些測試值得注意的幾個方面。

  >
  • >我們可以彼此嵌套測試塊。一個測試塊將包含用於TODO模型的所有單元測試，這些測試的子塊集中於初始化。 在測試塊中，我們可以定義每個測試之前執行的功能。這就是toteach（）塊的目的。在上面的示例中，我們正在每次測試之前創建一個todo的新實例。
  >
  • >摩卡摩卡框架會自動確保我們所有測試用例的JavaScript上下文（即，其值）是一致的。這就是為什麼我們可以在一個函數（toteARK（）參數）中定義this.todo並將其安全地引用其他函數（例如IT（）參數）。如果沒有摩卡咖啡在幕後工作以提供這種一致性，JavaScript將為每個功能定義不同的上下文。
  當然，由於我們尚未編寫模型代碼，因此我們所有的測試都會失敗。 （而且我們會立即知道。）但是，一旦我們添加了模型的代碼，測試就通過了。

  使用第三方功能的存根

  assert<span>.equal(sum, 4, "sum should equal 4");</span>

  >現在我們有了一個簡單的毒品模型，我們可以開始定義其行為。我們的模型應該做的一件事是在任何屬性更改時更新數據庫。但是，在單元測試環境中，我們將沒有實際的數據庫檢查。另一方面，我們實際上並未編寫任何代碼來進行數據庫更新。相反，我們依靠骨幹來處理這種互動。這暗示了此測試案例的單位測試策略。我們需要知道的是，骨幹模型使用save（）方法更新任何支持商店正在持續使用該模型。在我們的情況下，備份商店是數據庫。這是我們可以使用的單元測試代碼：

  >在每個測試之前，我們還包括一些其他代碼，並且在每個測試後都添加了一部分代碼以執行。該額外的代碼管理Sinon存根，該函數有效地將代碼中的另一個函數取消。在我們的情況下，存根將this.todo的save（）方法無效。有了存根，對該方法的呼叫實際上不會訪問後庫庫。相反，Sinon攔截了這些電話，並立即返回。這種行為很重要。如果我們試圖在單元測試環境中執行實際的骨幹保存（）方法，則該調用將失敗，因為不會有數據庫或服務器API。

  >存根後，我們的測試用例可以使用它來驗證模型的行為。在第一個測試案例中，我們立即將TODO的標題設置為新值。由於這更改了標題屬性，因此我們希望我們的模型更新其備份商店。為了檢查我們是否只驗證了該存根是被調用的。為了使我們的模型通過這些測試，我們可以尋找變更事件並做出適當的響應。

  <span>var sum = 2 + 2;</span>

  測試視圖
  當然，如果我們的應用程序實際上沒有向用戶展示Todos，那麼我們的應用程序將不會對任何人有任何好處，這需要創建一些HTML。我們將使用骨幹視圖來實現該功能。在我們瑣碎的應用程序中，我們只想將每個待辦事項作為列表項目。這是將使我們開始的測試用例。

  >

  assert<span>.equal(sum, 4, "sum should equal 4");</span>

  >我們通過兩個測試用例開始對視圖的測試。首先，我們確保視圖的渲染方法返回視圖本身。這是主鏈中常見且非常方便的慣例，因為它允許方法鏈條。我們的第二個測試用例驗證了渲染創建的HTML元素是列表項目（
• ）。通過這些測試所需的代碼是直接的骨幹視圖。
  接下來，我們可以開發該列表項目視圖的詳細內容。例如，我們希望完整的列表項目看起來像以下內容。

  <span>expect(sum).to.equal(4);</span>

  >
  對於我們的測試案例，我們可以利用jQuery從視圖的主要元素中提取單個元素。

  sum<span>.should.equal(4);</span>

  請注意，在上一個測試案例中，我們將模型的save（）方法固定了。由於我們正在從其默認值中更改屬性，因此我們的模型將盡職盡責地將其持續到其備用商店。但是，在單元測試環境中，我們將沒有數據庫或服務器API。該存根取代了缺失的組件，並允許測試無錯誤進行。為了通過這些測試通過，我們必須在我們的視圖中添加一些其他代碼。

  CREATE TABLE `todos` (
    `id`       int(11)      NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.',
    `title`    varchar(256) NOT NULL DEFAULT ''     COMMENT 'The text for the todo item.',
    `complete` bit(1)       NOT NULL DEFAULT b'0'   COMMENT 'Boolean indicating whether or not the item is complete.',
    PRIMARY KEY (`id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'
  

  >
  測試模型/視圖交互

  <span><span><!DOCTYPE html></span>
  </span><span><span><span><html</span> lang<span>="en"</span>></span>
  </span>  <span><span><span><head</span>></span>
  </span>    <span><span><span><meta</span> charset<span>="utf-8"</span>></span>
  </span>    <span><span><span><title</span>></span><span><span></title</span>></span>
  </span>  <span><span><span></head</span>></span>
  </span>  <span><span><span><body</span>></span>
  </span>    <span><span><span><h1</span>></span>List of Todos<span><span></h1</span>></span>
  </span>
      <span><span><span><script</span> src<span>="lib/jquery-1.9.0.min.js"</span>></span><span><span></script</span>></span>
  </span>    <span><span><span><script</span> src<span>="lib/underscore-min.js"</span>></span><span><span></script</span>></span>
  </span>    <span><span><span><script</span> src<span>="lib/backbone-min.js"</span>></span><span><span></script</span>></span>
  </span>    <span><span><span><script</span> src<span>="src/app-todos.js"</span>></span><span><span></script</span>></span>
  </span>    <span><span><span><script</span>></span><span>
  </span></span><span><span>      <span>$(function () {
  </span></span></span><span><span>        <span>var todos = new todoApp<span>.Todos</span>();
  </span></span></span><span><span>        todos<span>.fetch();
  </span></span></span><span><span>        <span>var list = new todoApp<span>.TodosList</span>({collection: todos});
  </span></span></span><span><span>        <span>$("body").append(list.el);
  </span></span></span><span><span>      <span>})
  </span></span></span><span><span>    </span><span><span></script</span>></span>
  </span>  <span><span><span></body</span>></span>
  </span><span><span><span></html</span>></span></span>

  >現在我們已經驗證了我們的視圖實現會創建正確的HTML標記，我們可以測試其與模型的交互。特別是，我們要確保用戶可以通過單擊複選框來切換A TODO的狀態。我們的測試環境不需要實際的人用戶，因此我們將使用jQuery生成點擊事件。但是，為此，我們必須將內容添加到真實的Live DOM中。該內容被稱為測試

  夾具

  。這是單元測試代碼。

  請注意，我們再次將todo's save（）方法固定。否則，當我們通過模擬單擊更改todo狀態時，骨干將嘗試更新不存在的備份商店。

  bash-3.2$ node --version
  v0.8.18
  bash-3.2$ npm --version
  1.2.2
  bash-3.2$
  

  對於測試用例本身，我們首先創建具有固定件ID的

  元素，然後將該元素添加到我們的實時文檔中。在這種情況下，實時文檔是顯示我們測試結果的網頁。儘管我們在驗證測試案例後立即刪除元素，但我們也將其顯示屬性設置為無，因此它不會干擾Mocha的測試結果。實現此功能的代碼包括對TODO模型的少量添加。添加是一種新的togglestatus（）方法。 >

  <span>var sum = 2 + 2;</span>

  在視圖中，我們想在元素上查看單擊事件，並為模型調用此方法。

  assert<span>.equal(sum, 4, "sum should equal 4");</span>

  測試集合

  在這一點上，我們的應用程序幾乎完成了。剩下的唯一功能是將所有招待員聚集在一起。自然，我們將使用骨幹收藏。實際上，我們不會在收藏中做任何特別的事情，因此我們真的不需要任何單位測試。

  但是，我們可以驗證我們對集合觀點的實施是否合適。我們希望該視圖呈現為無序列表（

  ）。測試用例不需要我們以前從未見過的任何功能。 >

  <span>expect(sum).to.equal(4);</span>

  視圖實現也很簡單。它跟踪集合中的任何添加並更新視圖。對於初始渲染（），它一次只會一次添加一個集合中的所有模型。

  >

  sum<span>.should.equal(4);</span>

  獎勵測試：驗證API

  CREATE TABLE `todos` (
    `id`       int(11)      NOT NULL AUTO_INCREMENT COMMENT 'Primary key for the table.',
    `title`    varchar(256) NOT NULL DEFAULT ''     COMMENT 'The text for the todo item.',
    `complete` bit(1)       NOT NULL DEFAULT b'0'   COMMENT 'Boolean indicating whether or not the item is complete.',
    PRIMARY KEY (`id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='To Do items.'
  

  由於我們的REST API完美地匹配了骨幹期望期望的API，因此我們不需要任何自定義代碼來管理API交互。結果，我們不需要任何單位測試用例。在現實世界中，您可能不會那麼幸運。如果您的API不符合骨幹慣例，則可能需要覆蓋或擴展一些骨幹代碼來處理非標準API。該額外的代碼也需要單位測試。幸運的是，即使在單元測試環境中，測試API交互也相對容易。

  測試API交互的最簡單方法依賴於sinon.js的假服務器功能。不幸的是，該功能僅在Sinon的瀏覽器實現中（當前）可用。它明確排除在Node.js實現中。有一些駭客可以在Node.js中運行它，但是這些駭客很脆弱，並且依賴於內部實現細節。如果可能的話，最好避免它們。幸運的是，如果沒有Sinon的假服務器，我們就可以通過。

  >秘密知道骨幹依賴於jQuery的$ .ajax（）函數來實現REST API。我們可以通過固定該功能來攔截API相互作用。當我們啟動功能時，我們將要替代自己的響應。 存根的屈服方法為我們提供了這個機會。它告訴辛農（Sinon）在稱呼該存根時應採取什麼其他動作。這是一個完整的測試案例，可以驗證我們的收集使用REST API正確初始初始初始初始初始初始初始初始初始初始初始。

  <span>var sum = 2 + 2;</span>

  完成！

  從隨後的屏幕截圖中可以看到，我們現在已經編寫了通過所有單元測試用例的代碼。至少目前，開發是完整的。

  >

  在集成期間進行測試

  >現在，我們的應用程序的客戶端開發已經完成（並且我們已經有了證明這一點的測試），我們可以將JavaScript安全地塞入源代碼管理系統中。然後可以將其集成到整個應用程序的構建過程中。作為該過程的一部分，我們希望執行我們開發的所有測試用例。這將確保構成最終部署的代碼通過我們定義的所有測試。它還將防止無意中引入新錯誤的代碼的“次要調整”。

  在構建過程中，我們可能希望從命令行執行測試，而不是在Web瀏覽器中執行測試。我們不需要單個測試用例的細節，只是保證它們都通過了。 Node.js非常容易適應這一要求。我們只需要對我們的源代碼和單元測試代碼文件進行幾個小添加。

  >

  我們的代碼需要這些修改，因為Node.js處理全局變量的處理方式與Web瀏覽器不同。在Web瀏覽器中，默認情況下，JavaScript變量在範圍內是全局。另一方面，node.js默認情況下將變量限制在其本地模塊中。在那個環境中，我們的代碼將無法找到所需的第三方庫（jQuery，下劃線和骨幹。 。

  >我們還需要調整測試代碼。測試腳本需要訪問自己的庫（jQuery，Chai，Sinon.js和Sinon-Chai）。此外，我們需要添加一些額外的內容來模擬Web瀏覽器的文檔對像模型（DOM）。回想一下，我們的點擊處理測試要求我們將“固定裝置”

  臨時添加到網頁。當然，Node.js通常沒有網頁。但是，JSDOM節點軟件包讓我們模仿一個。下面的代碼為我們的測試創建了一個最小的，模擬的網頁。 >

  <span>var sum = 2 + 2;</span>

  >包裝這些語句測試的條件，以查看我們是否在Node.js環境中運行，而不是Web瀏覽器。在瀏覽器中，不需要額外的語句，因此我們可以安全地跳過它們。

  >通過這些更改，我們可以從命令行執行完整的測試套件。只需導航到項目的根文件夾並執行命令摩卡咖啡即可。結果看起來很熟悉。

  >

  當然，摩卡咖啡返回出口水平，以指示是否通過了所有測試。這使我們可以將測試自動化為連續集成過程的一部分，或者僅僅是保留我們自己的理智的本地預設腳本。

  結論

  在這一點上，我們已經實現了目標。我們有一個單元測試環境在開發過程中在後台運行，並在任何測試失敗時立即通知我們。測試在網絡瀏覽器中執行，使我們在編碼時完全訪問了瀏覽器的開發工具。相同的測試也從命令行腳本同樣運行良好，因此我們可以在構建或集成過程中自動執行。

  資源

  這是文章中使用的主要單元測試資源。

  >

  >命令行JavaScript執行環境：node.js

  > JavaScript單元測試框架：Mocha
  測試開發環境：test’em
  > JavaScript斷言庫：Chai斷言庫
  間諜，存根和模擬：sinon.js
  其他斷言：sinon.js chai
  • >
  • 在單位測試backbone.js應用程序上的常見問題（FAQ）

  backbone.js中的單元測試與其他JavaScript框架相比？

  backbone.js與其他JavaScript框架一樣，支持單元測試以確保應用程序的質量。但是，由於其靈活性和簡單性，Backbone.js脫穎而出。它並不決定您的應用程序應如何構建，從而使開發人員可以自由設計自己的應用程序，因為他們認為合適。這種靈活性擴展到單元測試，使開發人員可以選擇其首選的測試工具和方法。此外，與其他框架相比，Backbone.js具有較小的佔地面積，使其用於單元測試更快，更有效。

  >

  >我可以在Backbone.js中使用什麼工具？是否可以在backbone.js中用於單元測試的幾種工具。一些受歡迎的包括摩卡咖啡，茉莉和開玩笑。 Mocha是一種功能豐富的JavaScript測試框架，可為開發人員提供一種測試其應用程序的簡單方法。茉莉花是用於測試JavaScript代碼的行為驅動的開發框架。它不依賴瀏覽器，DOM或任何JavaScript框架，因此非常適合測試backbone.js應用程序。另一方面，開玩笑是一種全面的測試解決方案，專注於簡單和支持大型Web應用程序。 Backbone.js應用程序的測試涉及為應用程序的每個組件創建測試用例。這包括模型，視圖和收藏。每個測試用例應涵蓋組件的特定功能，並應獨立於其他測試用例。您可以使用Mocha或Jasmine等測試框架來編寫測試。這些框架提供了定義測試用例，設置和拆除測試環境並做出斷言的功能。

  >

  >我如何在backbone.js？

  中運行單位測試？ JS取決於您使用的測試框架。例如，如果您使用的是摩卡咖啡，則可以使用Mocha命令行工具運行測試。如果您使用的是茉莉花，則可以使用Jasmine命令行工具運行測試。這些工具提供了運行單個測試用例，整個測試套件或應用程序中所有測試的選項。他們還提供了有關測試結果的詳細報告，包括通過，失敗和跳過的測試數量。

  我可以在Backbone.js.js嗎？自動化單元測試在backbone.js中。自動化涉及建立連續集成（CI）系統，該系統每當對代碼進行更改時會自動運行測試。這樣可以確保更改引入的任何錯誤都會立即捕獲。有幾種CI工具，例如Jenkins，Travis CI和CircleCi，它們支持JavaScript，可用於在Backbone.js中自動化單元測試。

  在backbone.js？

  >

  >我如何在backbone.js中調試失敗的單位測試？報告確定失敗的原因。大多數測試框架都提供詳細的錯誤消息，可以幫助您查明問題。您還可以使用chrome devtools或node.js debugger等調試工具逐步瀏覽您的代碼並檢查變量和函數調用。

  我可以在單元測試backbone.js嗎？ >是的，您可以在單元測試骨幹鏈中使用模擬和存根。模擬和存根是模擬真實對象行為的假對象。它們用於隔離系統的其餘部分。這使得測試更加可靠，更容易編寫。有幾個可用的庫，例如sinon.js，它們提供了創建和管理模擬和存根的功能。

  >

  >如何改善backbone.js中的單元測試的性能？ Backbone.js中單元測試的性能涉及優化您的測試和測試環境。這包括編寫有效的測試，這些測試快速執行，並行運行測試以及使用快速的測試框架。您還可以使用分析工具在測試過程中識別慢速測試和瓶頸。

  >

以上是單元測試骨幹。JS應用程序的詳細內容。更多資訊請關注PHP中文網其他相關文章！