視頻與幻燈片(含視頻下載): http://fronteers.nl/congres/2009 ... -Javascript-testing
演講很口語化, 且沒有抄本記錄, 因此翻譯的過程稍微刪減了一點無法聽清的內容與廢話. 但是大意應該沒有影響.
John Resig的演講已經逐漸從JS測試與性能剖析轉向了jQuery 1.4.x的宣傳.
這一部是他唯一集中講述測試的演講, 也是我認為最值得分享的.
JavaScript的測試似乎很少有人重視的樣子. 另一方面測試的實施也的確困難.
不過既然要把前端開發當作是專業獨立的職業來做, 實施測試真的很有必要.
即使沒有開發自己的庫/框架, 測試也可以建立起重構的基礎與代碼質量的信心.
[中括號部分一般是我加入的注釋]
--- 正文 ---
感謝大家. 也感謝主辦方邀我來此. 今天我想談一點JavaScript測試中的問題所在, 我個人重視JavaScript測試的原因 -- 我覺得其重要性甚至要超過服務器端程序的測試, 以及可行的實施測試的手段 -- 至少在我的經驗中是可行的. 希望能給未曾嘗試過JavaScript測試的童鞋們一點啟示.
一個最常問及的問題就是: 為什么要做JavaScript測試. 也許從一個服務器端程序員的視角來看JavaScript不過是小兒科(而不必測試), 也許問話者根本不了解測試. 而實際情況是: 為了兼顧多種運行平臺, 要想寫出高質量的JavaScript代碼, 很難. 我們得設法了解何處會碰到瀏覽器不兼容問題, 而測試可以幫我們偵測這類問題的所在.
我想強調的是JavaScript測試與服務器端/桌面應用程序的測試都有所不同. 在那兩種環境中, 測試的主要性質是回歸測試, 亦即對既有代碼的修改不會破壞軟件原有的功能. JavaScript測試也包含了這一方面, 但我們主要用它來偵測詭異的跨瀏覽器問題, 其效果比我們想象中要好得多.
當我們開始寫客戶端JavaScript代碼時, 肯定先要做這么一個研究: 兼容各種瀏覽器的成本與收益對比. 一般來說收益就等于某種瀏覽器的市場占有率--有多少用戶在用它. 而成本的意義則是我們在開發過程中要解決的瀏覽器bug. 當然, 各人面對的具體情況可能不同. 比如說你的網站訪客跟美國網民的統計結果很可能不同, 面向全球的網站, 比如雅虎, 和你的網站情況也未必一致. 開發者具體要支持哪些瀏覽器, 只有靠你自己心理有數了.
Yahoo做出了選擇并且把他們的瀏覽器支持表公布出來, 用于說明哪些瀏覽器他們會給予全力支持. 他們的QA試驗室里有專門的電腦來測試表中所有標作A級的平臺. 比如說Mac OS X 10.4上的Safari 3.2, 他們會真的弄一臺這樣的電腦, 然后抓一個人上去測試. 可能我們絕大多數人都沒有這樣的測試條件--畢竟這樣消耗的人力物力真的很大--專門雇用員工來做測試, 我真的很嫉妒.
jQuery項目的做法與此不同. 我們的方案是支持主流瀏覽器的當前版本, 前一版, 和下一版. 我們持續關注瀏覽器在新版本中的變動, 研究是否要予以支持. 這個表格是我們1.3版本的支持范圍. 下一版1.4版將會加入更多的瀏覽器支持, 大概二十到三十個版本這樣. 這個后面我還會談到.
現在有一個很大的問題是每支持一個新的平臺(瀏覽器+操作系統的組合)都可能會遇到新的兼容性問題, 測試正可以解決這個問題. 畢竟沒人能同時記住所有平臺上的兼容性問題, 即使是富有多年工作經驗的人也可能會被新的瀏覽器bug所困擾.
JavaScript測試框架已經出現了很多種, 因此不少人也會問: 用什么來測試. 上個月我做了一次調查: 你所使用的JavaScript測試框架, 大概收到了兩千多個回復. 從圖中可以看到: 前面幾個選項數量不少, 但是更多的數量分散在長尾中, 甚至有些測試框架只有一個人在用, 或者是自己寫成的測試框架. 然而, 不寫測試的數量還要大. 完全不測試JavaScript的人數幾乎占了一半. 恐怕實際上不寫測試的比例還要更大.
JavaScript測試框架的組成跟傳統的測試框架結構基本一致. 其中測試套件(Test Suite)包含多個測試(Test), 而每個測試又有一組斷言(Assertion), 斷言就是用來描述"這些為真, 那些為假"的方法. JavaScript測試需要能處理異步測試, 比如Ajax測試, 動畫, 延時等, 測試框架要了解這些異步事件的結束. 然后還要有一個總的驅動(Test Runner), 把這些測試加載運行起來. 這樣你只要用瀏覽器打開一個URL, 所有的測試都會自動跑完.
既然有些測試框架只有一個人在用, 這里我想說的是: 自己寫一個測試框架很容易. 要想理解JavaScript測試框架的運作, 最好就是自己寫一個測試框架, 而且真的很容易很容易. 比如基本的斷言部分只要4-5行代碼的樣子. 這里我來舉個例子.
我們先創建一個ul, 然后看這里的兩個斷言, 我們傳入true會得到一個成功的測試并顯示成綠色, 而傳入假值[包括0, 空字符串, null等]則會失敗, 顯示為紅色, 然后把測試結果記錄在此. 我們為斷言創建li元素, 用class表示通過/失敗. 這就是測試框架最核心的部分, 每個測試框架都是這么干的: 記錄測試結果, 然后用可視化的方法顯示出來, 整個過程很簡單.
接下來要做的是: 按照測試套件把測試結構化地組織起來. 一般來說一個測試中的斷言都圍繞著一個同方法. 只要多寫這么幾行, 就能把斷言分組. 下面是測試的代碼: 我們把一組斷言放到一個函數中表明他們有相互關聯. 這種語法很簡明直接, 而且框架結構也不復雜, 只有十來代碼.
最后我們要實現異步測試. 我來刷新一下這個頁面看看: 這兩個斷言測試了setTimeout--當然現實中我們沒必要測試它. 我們這里調用pause()函數就可以讓測試中止運行, 后面的測試都將在隊列中等待. 當我們再調用resume()的時候, 測試又將繼續運行下去. 這樣我們可以在同一個頁面中混合運行同步與異步測試. 這樣一個測試框架只需二十幾行代碼. 既然寫一個測試框架都如此簡單, 沒理由不來上手用一下.
下面這個頁面其實就是用來加載測試的, 看上去很華麗. [然后這一坨沒怎么聽清...大意就是講需要一個測試驅動來加載與運行測試, 有些測試框架有自己的加載過程而有些沒有, 而Dojo的測試驅動更華麗一點, 可以自行選擇暫停/繼續.]
我估計今晚就會有人開始動手寫自己的測試框架, 不過現今流行的測試框架已經很優秀了. 根據我的調查, QUnit, JSUnit, Selenium和YUI Test最為流行. 后面就是長尾. 下面我會談談這前四名, 但愿能給你帶來一點JavaScript測試的感覺.
我認為單元測試(Unit Testing)的目的就是把代碼按照邏輯分割開來, 一般會按照方法[亦即函數]來分割. 每一組斷言都在圍繞API中的一個方法來測試. 這很適合測試庫/框架的API. 適合單元測試的流行框架包括JSUnit, QUnit和YUI Test.
JSUnit給我的感覺很..2001, 感覺它是生于那個年代的JavaScript代碼. 我這里沒有展示它的源碼. 不過如果你看一眼其中的驅動部分, 我用Firebug查找運行的測試數目的時候, DOM里全是, , 不過好像沒什么
--他們直接用frame來布局, JSUnit很久沒有維護了. JSUnit基本上就是Java中的JUnit移植到JavaScript的樣子.
這就是JSUnit的測試文件, 代碼風格很像Java. 對這個框架我很失望, 陳舊且缺乏更新. 有些人還在使用也許只是因為習慣而已.
下面是YUI Test, 與YUI2一起發布于去年年末, 新版與YUI3共同發布. 雖然問世至今僅一年但已經很是流行--因為它的確很優秀. 對異步測試也有支持. 我最喜歡它的事件模擬功能. 比如你想模擬對鍵盤輸入, 鼠標點擊等事件的測試, YUI對此有很好的支持.
這就是YUI Test2的測試代碼, 結構很清晰, 支持setup/tearDown為每個測試做準備/清理工作. 測試驅動最終在網頁中生成一個彈出式的控制臺來包括結果. YUI Test3語法上更好一點, 但整體區別不大. 控制臺更光鮮一點, 加上了一點色彩漸變, 并且加入了運行時間的統計.
然后是QUnit, 這是我們用來測試jQuery的框架. 我們把QUnit寫成了獨立的項目, 現在它不再依賴jQuery運行. 它支持異步測試, 依模塊分類--比如把所有Ajax測試歸結到一起, 還有測試時限, 比如限定一個測試必須在10秒鐘內結束, 如果超時的話就按照失敗處理, 這在異步測試中很有用.[然后又是一坨聽不清的]
QUnit的語法跟我之前展示的迷你測試框架一樣. 這里有測試, 斷言, 模塊分組. 然后這個頁面是驅動部分. [屏幕切換中] 這個是QUnit的網站, 完整的API文檔都在這, 功能很少, 畢竟測試只需要這么幾個方法, 不必搞得很復雜.
下面我要展示一些實際的測試代碼, 這是我們用來測試jQuery的代碼. 我們為jQuery寫了兩千多個測試, 而且越寫越多. 完善的測試覆蓋給jQuery項目幫助很大, 確保我們做出修改時不會制造麻煩. 特別我們團隊在地理上高度分散, 沒法聚到一起解決問題, 因此這樣的自動化測試顯得格外重要. 還有一個功能是指定測試中運行的斷言數目. 比如我們這里指定要運行16個, 如果實際上只完成了15個, 那么測試會被記作失敗. 這樣可以確保一些條件分支中的測試能運行[異步測試同樣受益]. 也可以雙擊某一個測試來單獨運行它.
我還寫了一個測試框架名為FireUnit. 是Firebug的單元測試插件. 可以在Firebug里完成測試. 在FireUnit的網站上就嵌入了一段測試代碼. 在Firebug控制臺里可以看到鏈接至源碼的測試結果, 而且包括調用棧跟蹤.
社區正在為標準化做出努力. CommonJS規范致力于為客戶端與服務器端定義一個通用的API. 包括模塊, 打包, 單元測試等. 前段時間我跟他們交流了一下, 就API的設計達成了一致觀點, QUnit也接受了這個API. 希望JavaScript測試框架能向這個方向靠攏.
下面我想講一點行為測試與行為測試開發. 這方面有兩個較為流行的框架是Screw.Unit與JSSpec. 行為測試更適合于測試實際的網站而不是簡單的API測試. 雖然對API的測試不難, 但問題是我們大多數人在做的是網站而非框架/庫, 而對實際網站的測試也不能忽視. 一個很優秀的工具是Selenium, 它能記錄并自動測試網站上的行為. 他們還做了一個Selenium IDE, 是Firefox擴展, 用來記錄操作并重放.
這里我來展示一下, 這是它的IDE窗口, 點擊錄制, 然后我回到網頁這邊, 點擊下載, 搜索教程. 然后在IDE這邊可以看到我們的點擊和等待操作都被記錄下來了. 然后我們停止記錄并重放這些動作, 一切都能自動化地重現了. 操作記錄文件可以保存下來, 并儲存成Ruby, Java等多種語言文件. Selenium可以據此在后臺自動啟動瀏覽器, 運行測試, 并將測試結果與服務器端測試報告整合起來. 功能的確很強大.
Selenium還能偵測頁面元素, 比如驗證頁面上是否出現了某些文字, 某個按鈕是否存在等等. 這可以用來驗證網站是否正常工作, 包括內容動態的頁面, 比如驗證JavaScript制作的動態UI.
JavaScript測試的又一個發展方向是在服務器端模擬瀏覽器環境. 一般用Java或JavaScript寫成, 然后配合Rhino引擎測試. Rhino是JavaScript的一個Java實現. 因此它脫離瀏覽器單獨運行.
這幾個框架可以幫你在Rhino中模擬瀏覽器環境, 用以完成無瀏覽器的測試. 其中我寫了一個Env.js, 完全用JavaScript模擬瀏覽器環境. 下面我再演示下.[無意義叨叨一陣]. 這里我給window.location賦值用來加載頁面, 有window和document對象. Env.js的特色是: 當你檢視一個函數時可以看到它的源代碼而不是[native code], 因為它完全是用JavaScript寫成的.
Env.js制造的瀏覽器環境可以運行起大多數流行的JavaScript框架, 比如jQuery, Prototype, 用它們做服務器端的程序. 我聽說有人基于這個環境寫了網頁抓取的程序, 當時我就震驚了--畢竟Env.js還沒有達到生產環境可用的程度. 甚至還有人據此寫了完整的服務器端框架--我不想說這玩意很像Rails, 不過它的確很像. 但是它能在服務器端直接操作DOM, 改變內容, 然后再發送到客戶端. 這樣客戶端與服務器端可以同時運行諸如表單驗證, 模板等代碼. 服務器端JS是一個很大的話題, 這里我不再多談, 但是我建議各位關注一下.
關于模擬瀏覽器測試我想再提一點, 盡管運行速度很快, 反饋及時, 但是這還是不能替代真正的瀏覽器測試. 它距離現實情況太遠, 這些模擬框架都是作者們在嘗試模擬瀏覽器的工作方式. 包括一些模擬器--比如在Mac系統中模擬Win平臺下的IE, 或者桌面上的手機瀏覽器模擬--這些都不能跟真實的測試相比擬.
現在問題又來了, 我們要測試多個平臺, 但有需要能自動化測試的方法. Selenium有這么一套完整的解決方案, 這里有一個組件是Selenium Grid. 它可以把你的測試推送到Amazon云服務上, 在多個平臺自動進行瀏覽器測試.
我寫的一個方案叫TestSwarm. 工作方式與Selenium Grid相似. 不過區別在于你要自己假設服務器并推送測試, 而且需要有志愿者訪問服務器來做測試. 稍候我將詳述.
不過在你的公司里, 現實情況可能是有那么一兩臺測試機器, 安裝了各種瀏覽器, 然后你想自動啟動瀏覽器來運行測試. 這種情況我們只需要引導瀏覽器即可. 這里大多數引導工具是用Java寫成的. 也可以把這些工具集成到開發流程中, 讓他們自動報告測試結果. 比如這里Google發布的JsTestDriver, 它與Eclipse集成良好, 可以自動地即時獲取測試反饋. 可行的解決方案還有很多.
下面我要談的是擴展問題. 我們要支持的瀏覽器平臺越多, 自動化測試越困難. 特別是對每次代碼提交都要測試時難度更大. 因此JavaScript測試的擴展性并不好.
我寫TestSwarm的原因就在這里. 開發者只需建立起中心服務器, 服務器從開發者處收集測試套件, 測試者訪問服務器就可以開始自動運行測試, 測試的結果將被服務器自動統計起來. 這張圖簡單展示了它的工作機理.
下面要談的是手動測試. 比如你想測試UI操作流程并記錄整個操作過程. 這就要向測試者給出指示: 這有個對話框, 把它拖拽到另一邊, 拖拽正常嗎? 有否出現視覺上的瑕疵? 這可以是分布式手動測試的一個思路.
我們建立了高分榜來鼓勵測試. 運行測試多的人可以拿高分, 我們可能會依照分數發點小禮品. 我再展示一下: 這里是TestSwarm的站點, 上面顯示的是已經連接到服務器的不同瀏覽器數目. [叨叨, 不知所云] 下面是jQuery項目中與代碼版本歷史相結合的測試結果一覽, 垂直方向上的是修訂版, 水平方向是瀏覽器. 實際測試的瀏覽器種類遠超過之前提到的11種. 現在差不多有50種了. 這里有一次版本提交造成了測試失敗. Opera是測試失敗最多的瀏覽器. 這種測試可以幫我們更好地了解全局, 比如Windows 2008上的IE8可能跟Vista上的IE8行為不同, 未來Win7上的IE8可能還會有變異.
下面我展示一下如何運行測試. 在這輸入我的用戶名, 然后點連接. 這里會收到jQuery UI測試套件并在后臺自動運行. 然后客戶端會周期性地詢問服務器是否有新的測試任務. 所以我們只要打開瀏覽器, 開幾個標簽頁, 就能自動運行測試并收集測試結果.
[各種念叨...大意是說這樣大規模的分布式測試有助于抹去個體不確定性(比如個人網速慢, CPU忙碌等)造成的測試誤差]
http://bbs.blueidea.com/viewthread.php?tid=2981536
it知識庫：2009年11月John Resig(jQuery創始人)在荷蘭Fronteers大會上的演講.，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
