Ajax基礎教程（6）- 6.1 JavaScript提出的問題

讀到這裡，應該很清楚了，要想真正很好地使用Ajax，你就要寫一些JavaScript代碼。儘管架構和工具包能減輕一些負擔，但是最終你可能會得到比平常更多的JavaScript代碼。因為我們自己寫過不少，所以很清楚寫JavaScript代碼絕不是輕而易舉，不過，本章我們還是要在你筋疲力盡的肩頭再壓上幾塊石頭。

具體地，我們將介紹測試驅動開發（test-driven development，TDD），並展示開發JavaScript代碼時如何應用TDD。儘管這種方法不能馬上解決你的所有編程問題，但至少能協助你儘快完成工作，能按時回家與家人共進晚餐。我們先對TDD和廣泛使用的JUnit做一個簡要介紹。打好基礎之後，我們將討論JsUnit，並說明如何編寫和運行測試。

6.1　JavaScript提出的問題

如果你參與過Web應用的開發，可能已經寫過一些JavaScript代碼；當然，如果你只是寫了一些最簡單的函數，那麼對JavaScript的看法可能不會太好。瀏覽器不相容，缺少優秀的開發工具，沒有程式碼完成（code completion）之類的生產力工具，沒有調試工具——這麼多的缺點，足以讓大多數開發人員更樂於使用vi[1]。

我們很清楚你的這些苦衷。在第5章中，已經討論了許多工具，它們能讓你的日子更輕鬆。本章將介紹如何讓開發JavaScript儘可能地容易（至少，在工具開發商迎頭趕上之前，這種方法很合適[2]）。採用測試先行（test-first）的方式來編寫JavaScript，能大大簡化整個開發過程。

6.1.1　測試先行方法介紹

是的，現在肯定有讀者會這樣說了：“我只在產品發品之前寫測試。”有些人可能會竊笑，對品質保證部門說三道四。還有一些人作為專案經理可能會添油加醋地說：“我們可不會浪費時間寫測試代碼；我們還得寫真正的代碼呢。”那麼，採用TDD到底是什麼意思呢？

TDD產生于敏捷開發運動，特別是極限編程（extreme programming，XP），而且TDD正是XP的一個核心原則。推崇TDD的人認為，不應該完成開發之後再寫測試，這通常只是“馬後炮”，而應當在寫代碼之前先寫測試。測試本質上相當於設計文檔，而不是花大量時間去擺弄一個複雜的圖形化工具，你要直接在代碼中“擬畫”一個類。開始時先為一些小功能塊編寫測試。在有些語言下，你寫的測試甚至不能編譯，因為所引用的類尚不存在。一旦建立了測試，就可以運行這個測試（當然，此時運行測試會失敗）。然後再編寫最少量的代碼，以便測試通過。接下來再重構代碼，並增加更多的測試。

通常可以使用測試架構來協助編寫自動化測試。最著名的架構是JUnit，不過現在已經有很多xUnit項目，可以簡化在各種語言下測試的建立。一般地，這些架構都建立在斷言（assert）基礎上。開發人員編寫測試方法，將調用方法的實際結果與期望結果進行比較。當然，可以人工地檢查一個記錄檔或使用者介面來完成這些比較，但是，用電腦完成資料比較不僅速度快，也更準確。另外，就算是讓電腦把同樣的測試回合上1500次，它們也不會嫌煩，如果是人可做不到這一點。

有了JUnit和其他測試架構，編寫和運行測試變得相當簡單。這就能鼓勵開發人員建立大量測試（往往能更完備地覆蓋各種測試情況），而且會樂於經常運行這些測試（可以更快地協助開發人員找到bug）。在許多情況下，如果項目中採用了TDD，測試代碼往往與生產代碼一樣多！

使用TDD可以帶來許多重要的好處：

提供明確的目標：你很清楚，一旦結束（也就是一旦測試通過），你的工作就完成了（假設你的測試寫得很好）。測試會為代碼建立一個自然的邊界，使你把重點集中在當前任務上。一旦測試通過，就有確切的證據證明你的代碼能工作。相對於人工地測試使用者介面或者比較記錄檔中的結果，在一個xUnit架構中運行自動化測試，速度要快幾個數量級。大多數xUnit測試的運行只需幾微秒，而且大多數採用TDD的人都會一天運行數次測試。在許多開發小組中，將代碼簽入原始碼樹之前，代碼必須成功地通過測試。

提供文檔。你是不是經常遇到看不懂的代碼？這些代碼可能沒有任何文檔說明，而且開發代碼的人可能早就走了（或者度假去了）。當然，看到這種代碼的時間往往也很不合時宜，可能是淩晨3點，也可能有位副總在你旁邊大聲催促著趕快解決昨天的問題，這樣要想花些時間來明白原作者的意圖就更困難了。我們見過一些好的單元測試文檔，它們會指出系統要做什麼。測試就像原開發人員留下的記號，可以展示他們的類具體是怎麼工作的。

改善設計：編寫測試能改善設計。測試有助於你從介面的角度思考，測試架構也是代碼的客戶。測試能讓你考慮得更簡單。如果你確實遵循了“盡量簡單而且行之有效”的原則，就不會寫出篇幅達幾頁的複雜演算法。要測試的代碼通常依賴性更低，而且相互之間沒有緊密的聯絡，因為這樣測試起來更容易。當然，還有一個額外的作用，修改起來也會更容易！

鼓勵重構：利用一套健壯的測試集，你能根據需要進行重構。你是不是經常遇到一些不知是否該修改的代碼？種種顧慮讓你行動遲緩，過於保守，因為你不能保證所做的修改會不會破壞系統。如果有一套好的單元測試集，就能放心地進行重構，同時能保證你的代碼依然簡潔。

提高速度：編寫這麼多測試會不會使開發速度減慢呢？人們經常會以速度（或開發開銷）作為反對進行TDD和使用xUnit架構的理由。所有新的工具都會有學習曲線，但是一旦開發人員適應了他們選擇的架構（通常只需很短的時間），開發速度實際上會加快。一個完備的單元測試集提供了一種方法對系統完成迴歸測試，這說明，增加一個新特性之後，你不必因為懷疑它會不會破壞原系統而寢食難安。

提供反饋：單元測試還有一個經常被忽略的優點，即開發的節奏。儘管看上去好像無關緊要，但通過測試之後你會有一種完成任務的成就感！你不會成天地修改代碼而沒有任何反饋，這種測試—代碼—測試的方法會鼓勵你動作幅度小一些，通常修改一次代碼的時間僅幾分鐘而已。這樣你不會一下子看到冒出一大堆的新特性，而只是讓代碼基一次前進一小步。

從我們的經驗看，測試是會傳染的，你可能會慢慢上癮。一開始，許多開發人員都心存疑慮，但最終幾乎每個開發人員都迷上了運行測試後的綠條[3]。測試第一次“抓住”bug或者增加一個新特性，只需幾分鐘而不是幾個小時，往往就是在這樣一些時候，開發人員會欣喜地認識到測試確實很有意義。