單元測試101：你測試你的javascript嗎？(6)

　　21. pieces.push(format(num, consider[i]));

　　22. }

　　23. }

　　24.

　　25. humanized = (pieces.length == 1 ? pieces[0] :

　　26. pieces.slice(0, pieces.length - 1).join(", ") + " and " +

　　27. pieces[pieces.length - 1]);

　　28. }

　　29.

　　30. return future ? "in " + humanized : humanized + " ago";

　　31. };

　　注意，我沒有碰jQuery插件。因為我們分離了無關的部分，我可以完全自由的修改和提升人性化字符串的方法，而不改變我的網站中jQuery使用人性化字符串的方法。

　　持續集成

　　TDD實踐中，我們需要及時的反饋。反饋來自我們的測試，這意味著測試需要運行的輕松快速。JsTestDriver已經使測試運行的容易而快速，但總有局限性。限制來自多瀏覽器的形式。JsTestDriver能如你所愿在多個瀏覽器上容易的運行測試，因以下兩個原因，這對TDD工作流這樣做是不便的：

　　每一次從多個瀏覽器得到測試報告，使它更難看到發生了什么，并失去了TDD給你帶來的便利。

　　一些較弱的瀏覽器，而通常是重要的測試對象，是緩慢的。我的意思是慢的足以毀滅TDD流程。(And I mean slow.Slow ruins the TDD flow.)

　　解決這個問題的一個方案是持續集成。持續集成是自動和經常進行產品質量控制的實踐。這時應該包含進來一些工具，如JsLint，而它當然應該包含運行測試。

　　一個持續集成(CI)服務器可以確保所有開發者的工作可以正確的組合，并且負責在指定的多個瀏覽器是執行測試。一個構建的CI服務器通常由版本控制系統觸發，如Git或Subversion，并且一般提供當發現問題時給項目成員發送郵件的功能。

　　我最近寫了為JsTestDriver創建Hudson CI服務器指南。使用Hudson和JsTestDriver，很容易創建一個高效高質量的工作流程。對我自己而言，我基本是做什么都是TDD，通常我在本機的Firefox上運行測試，它是我發現具有最好錯誤信息和跟蹤信息的瀏覽器。每次我完成一個功能，通常很小，我把它放到代碼庫中。這時，Hudson檢出我剛提交的變化并在廣泛的瀏覽器上運行所有的單元測試。如果有測試失敗，我會收到一個說明發生了什么的郵件。此外，我可以隨時訪問Hudson服務器查看項目構建視圖，看個人的控制臺輸出等等。

　　結論：為什么我要關心

　　如果，在閱讀完這篇文章之后，你還不確信單元測試是一個很值得做的實踐，讓我們再重述一下一些常見誤解。

　　我使用一個庫，如jQuery，它確保我的代碼正確的工作。

　　Ajax庫，如jQuery，在幫助你處理跨瀏覽器問題上走了很遠。實際上，在很多情況下，這些庫完全抽象掉了所有這些討厭的DOM缺陷，甚至是核心JavaScript的差異。然而，這些庫沒有，而且不能，保護你的錯誤的應用邏輯，而單元測試可以。

　　測試是對專業人員的高級實踐，不適合我

　　我的立場是無論你認為你寫代碼的過程是哪種方式，你都在測試它，例如，通過刷新瀏覽器來驗證是不是按它應該的方式工作。你簡單的選擇了不參與自動化和提高你的測試過程，并且在長時間運行(或不那么長時間的運行)中，你花費時間在猛擊你的瀏覽器刷新按鈕，而我花費時間寫測試，然后我可以今天、明天或明年愉快的運行它。

　　像任何新技術一樣，測試需要實踐，但不需要一個“忍者”去做。測試由大量簡單的語句組成，他們使用你的代碼并對它做假設(真不好表達，原文：ests consistlargely of dirt simple statements that exercise your code and make assumptionsabout it.)。困難的部分是良好設計的代碼并確保它是可測試的。換句話說，困難的部分是提高你的編程技巧并寫之前思考你的代碼。無論是專業人員或初學者，任何人沒有原因不想提高

　　測試太花時間了，我只想寫產品代碼

　　手工和自動化測試都花時間。但是，不用花一兩個小時“評估”單元測試和/或TDD，然后決定它是在浪費時間。單元測試和TDD需要的是實踐，像其他任何科目一樣。沒有辦法幾個小時內做到擅長良好的自動化測試。你需要練習，而一旦掌握，你就會認識到我這里說的好處，并且認識到手工測試是多么的浪費。此外，如果你寫了單元測試，并花一些時間嚴厲測試你的代碼，你會選擇什么呢?失敗的真快，或能成功嗎?

　　調整你的需求

　　從這篇文章中你可能得到這樣的印象，我覺得各個人都應該采用我的工作方式。我沒有那種感覺。但我感覺認真對待應用的質量和正確性是很重要的，并且我認為單元測試是實現的完整部分。(I do think thatunit testing is an integral part of that equation.)

　　這里TDD更多是一個可選部分，但我的經驗告訴我，TDD極大的簡化單元測試。在我實現功能之前，它幫助我提升代碼設計，幫助我只實現那些必須實現的代碼。當然你可以采用其他的方式也很好的實現這個目標，但是對我來說，TDD是個完美的方案。

　　現在開始實踐吧!

　　About the Author

　　Originallya student in informatics, mathematics, and digital signal processing, ChristianJohansen has spent his professional career specializing in web and front-enddevelopment with technologies such as JavaScript, CSS, and HTML using agilepractices. A frequent open source contributor, he blogs about JavaScript, Ruby,and web development at cjohansen.no. Christian works at Gitorious.org, an open source Git hosting service.

　　Find Christianon:

　　§ Twitter - @cjno

　　§ Christian'sBlog

　　§ Christian's Book - Test-Driven JavaScriptDevelopment

　　原文地址：http://msdn.microsoft.com/en-us/magazine/gg655487.aspx

　　由于本人水平有限，雖然花費了大量的時間來翻譯，錯誤難免。歡迎大蝦批評指正。

原文轉自：http://www.anti-gravitydesign.com