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