2012-01-22 51 views
4

我寫的有以下堆棧實時JS應用:測試的Javascript

  1. 的Node.js服務器
  2. Socket.io作爲前端的通信層
  3. 的JQuery操縱DOM等

對於#1,我絕對沒有問題的測試。我目前正在使用nodeunit,這是一個非常出色的工作。

對於#3,我試圖弄清楚我的測試方法有點麻煩。

我的瀏覽器端代碼通常是類似的東西:

var user = { 
    // Rendered by html 
    id: null, 
    roomId: null, 
    foo: null, 

    // Set by node server. 
    socket: null, 
    clientId: null, 
    ... 
} 

$('button#ready').click(function() { 
    socket.emit('READY'); 
}); 

socket.on('INIT', function(clientId, userIds, serverName) { 
    user.clientId = clientId; 
    user.foo = (serverName == 'bar') ? 'bar' : 'baz'; 
}); 

,我想測試的主要組成部分包括檢查如果在服務器觸發某個分組與在瀏覽器端的JS會做出相應的反應指定參數:

ie user.foo =(serverName =='bar')? 'bar':'baz';

如何解決這個問題的任何好建議?

回答

0

多達樞紐對茉莉的支持是有點碰運氣(最小的新的發展,許多懸而未決的問題,對他們的github /拉請求),Jasmine是測試客戶端代碼一個很好的工具,主要是因爲的jasmine-jquery

Jasmine的一般方法非常穩固,Jasmine-Jquery有很多用於測試DOM的很好的匹配器,以及很棒的DOM沙盒。

我發現在客戶端測試是一個挑戰,主要是因爲我必須停下來是如此嚴格和規範在我的測試。

一般來說,你應該採用一種'模糊'的方式來進行客戶端測試,特別是測試DOM層次結構是一條通向地獄的道路。測試的東西,比如「頁面是否包含這些單詞」over「是否div id#my-div包含一個帶3個li的ul,內容與此正則表達式匹配」

後者是我如何開始做測試,但是我發現它令人難以置信的耗時和脆弱;如果設計師(我)想要弄亂這個結構,它可能會不必要地破壞很多測試。解決這個問題的唯一方法是爲每個組件創建「小部件」,這將是理想的,但正如我所說,這非常耗時,它實際上在我的辦公室成了一個跑步笑話:「本週Tim做了多少測試? 2?3?哇3測試,良好的工作。「

反正...

您可以通過測試鬆散,並專注於什麼是重要的,如工作流和數據「存在」在具體內容中的特定位置獲得90%做客戶端測試的好處頁面上的層次結構。

編輯:另外,還要確保你打破業務邏輯爲獨立於DOM的單位,儘可能力所能及的。這會讓你的生活變得更輕鬆,並且通常會帶來更好的體系結構,這是一個好的選擇。

編輯2:您可能想了解Rails世界如何使用水豚/黃瓜或硒來做這件事。

1

結賬Mocha。它在節點和瀏覽器中都有很好的支持。我發現它更適合其他選擇(茉莉花,誓言)。

另外,我不是運行像Selenium這樣的重量級集成設置,而是使用Zombie在一個進程中運行服務器測試和瀏覽器測試。它允許一些漂亮的集成工作流程(如觸發瀏覽器上的某些內容,然後驗證服務器上的效果)。

但是YMMV作爲殭屍是依靠JSDOM(DOM重新實現在Javascript中)。有修補/固定的粗糙邊緣,東西休息。如果這是一個問題,使用真正的瀏覽器在瀏覽器中運行Mocha(也許通過Selenium利用)。