測試驅動javascript開發 — 1.單元測試

文章目錄

• 　　單元測試的好處
• 　　單元測試面臨的困難

　　從今天開始，我將以讀書筆記的方式向大家介紹《Test-Driven JavaScript Development》相關內容。我不太清楚這本書是否已經有了中文的譯本，有興趣的朋友可以去搜尋下，或者直接讀英文原版。因為是讀書筆記，算是供大家參考學習的資料，所以文章中很多知識或者概念的定義或者講解可能不會那麼精確。只要大家能明白我表達的內容即可，沒必要太較真。

　　之前我寫了《QUnit系列》有興趣的朋友可以去閱讀，他是當前比較流行的javascript測試的架構。通過學習QUnit相關知識，覺得很有必要豐富下自己的理論知識。只有有了強大的理論基礎，你在工作上才會更有指導性和針對性。

　　本文將介紹單元測試的相關知識，單元測試的好處和他面臨的困難。

 

　　什麼是單元測試

　　簡單而言，單元測試是用來測試生產代碼的一段代碼，他通過在已知狀態下設定一個或多個對象，執行測試代碼，檢查輸出結果與期望值是否一致。他應該具有下面一些特點：容易開發、快速運行、在隔離的環境中測試軟體組件（每個測試之間不能相互影響，保持原子性）、可重複執行等。開發單元測試的過程中，我們可能還需要使用 mock 或者 stub 方式去類比依賴操作。

　　單元測試應該在下面的情況下運行：

• 代碼開發完成之後，驗證相關功能的正確性；

• 代碼發生改變的時候，驗證它的行為沒有發生改變；

• 當系統添加了新的單元項時， 確保他的功能正確，並保證沒有對系統造成影響。

 

　　在實際的工作中，大家可以使用市面上已有的測試架構進行開發，沒有必要自動再動手製作自己的架構。這樣做，一則可以減少開發時間、提高開發速度，再則別人架構已經提供了完善的相關api、架構也比較穩定，你不能保證你的架構就一定比別人的好。可選擇的架構比較多，例如：QUnit，JSUnit等，大家可以自行找資料學習。如果學習QUnit，可以參照我之前的博文《QUnit系列》，或者去官網學習。

 

　　單元測試的好處

　　測試是一份投資，然而有些人反對單元測試，覺得他是在浪費時間。寫單元測試確實需要時間，但是如果不使用它，有更好的辦法嗎。我們能做的恐怕只有執行一遍遍效率低下的手工測試了，而且還不一定能保證對系統的完全測試，要麼就是直到問題產生的時候再測試。顯而易見，單元測試還是有它的價值的，寫一次測試代碼，運行多次，當然有時候也需要對測試代碼本身加以維護。

　　1.迴歸測試

　　在開發的過程中我們難免會犯錯誤產生一些bug，這些bug直到生產環境才發現。有時候我們修複了這個bug，但是產品發布的過程中也許會犯別的錯誤，導致這個bug沒有修複或者再次出現。迴歸測試可以協助我們解決這個問題。在產品發布之前，優先運行它，能夠協助我們即時捕獲問題，得以確保產品品質。而且隨著系統的變化，系統會變的越來越大，業務也許會變的越來越複雜。傳統的人工迴歸測試可能難以應對（並不是說人工測試變的不重要），自動化測試會變得越發重要。

　　關於這點我深有體會，因為之前的公司對產品品質相當看重，系統建立了一整套機制協助開發和維護人員及時發現系統存在的問題。這套機制包括：記錄系統錯誤記錄檔、自動化測試、集[代碼嵌入-單元測試-demo伺服器發布]於一體的build系統、還有就是傳統的人工測試。在產品發布之前會先運行自動化測試，確保demo環境中的系統核心功能沒有受影響。自動化測試通過之後才能進行產品發布。產品發布之後，會再次運行自動化測試，確保現網核心功能沒有問題。自動化測試對保證產品品質起到了相當重要的作用。

　　當然，自動化測試有它的優勢也有不足，所以還需要進行人工測試，共同保證產品的品質。

　　2.重構

　　重構就是在不影響代碼功能的前提下，對他進行修改。例如：從一個方法中抽取一個協助方法，保證代碼的重用性，這就是重構；再或者對象或者方法的名字進行了修改，這也是重構。重構對於不斷演化的系統，保持其架構設計的健壯性、重用性、靈活性有著相當重要的作用。當然，你需要在重構之後運行單元測試，這樣才能保證你的重構對系統沒有產生不良的影響。

　　3.跨瀏覽器測試

　　對於web開發人員來說，我們開發的代碼是要在不同的平台、不同的用戶端上啟動並執行。使用單元測試可以有效減小我們測試的工作量。正所謂寫一次測試代碼，運行多次，我們可以在不同平台的不同用戶端上運行我們的測試代碼，保證我們的產品在不同環境下正常工作。

　　4.其他好處

　　精心編寫的測試，對於系統來說相當於一份很好的說明文檔，他可以協助新來的開發人員更快的瞭解系統和相應功能。此外，通過編寫測試，也可以協助開發人員理清代碼開發的思路。

 

　　單元測試面臨的困難

　　些單元測試其實不是件容易的事，寫出良好的單元測試需要不斷的實踐，是件具有挑戰的事情。上節中提到的單元測試的好處，是建立在遵循最佳實務的基礎上獲得的。如果你寫的是糟糕的單元測試，情況則完全不同，你會發現這種測試完全是在浪費時間，而且增加了維護成本。

　　為了寫出好的單元測試，你必須保證你的代碼是可測試的。當你為一個可測試性不好的系統引入測試的時候，你會發現你的工作完全是一項不可完成的挑戰。反過來也說明，單元測試對於暴露緊密耦合的代碼和分離關注點是有協助的。

　　本書會通過一些具體的執行個體，來向大家介紹如何編寫可測試的代碼，以及如何寫出好的單元測試。

 

　　學學單元測試真的挺好，除了可以用來提高產品品質外，對於提高自己代碼書寫品質還是有協助的，可以讓自己養成很好的代碼編寫習慣。