本書介紹

JavaScript專業開發人員必須具備的一個技能是能夠編寫可測試的代碼。不管是創建新應用程序，還是重寫遺留代碼，本書都將向你展示如何為客戶端和服務器編寫和維護可測試的JavaScript代碼。

從減少代碼復雜性的方法，到單元測試、代碼覆蓋率、調試、以及自動化，您將全面學到如何編寫讓你和你同事能夠輕松修復和維護的JavaScript代碼。測試JavaScript代碼是一個復雜的過程。本書將在很大程度上幫你簡化該過程。

目標讀者

本書主要目標受眾是那些想成為JavaScript專業開發人員的人。初中級水平、或者專家級別的開發人員都適合閱讀本書。因為每個人都可以從本書獲取有用的知識。

JavaScript可能不是我們所使用的唯一語言，但在編寫或測試程序時要用到大量JavaScript。如果有人付費讓你編寫JavaScript代碼，如果你每天都用JavaScript編寫不同大小項目的話，本書正是你的不二選擇。

如果你加入了一個必須要測試JavaScript的QA或工具團隊，本書也適合您閱讀——第3章到第7章非常值得一讀。本書的目的是使測試盡可能容易，進而全部自動化。希望這本書能使大家的工作更輕松。這就是我要達到的目的。

如果你編寫JavaScript不太多，這本書仍會為你提供很多有用的信息——特別是復雜度（第2章）、基于事件的架構（第3章）、以及調試（第7章）的這些章節。注意，其余章節也有很多有用的信息，但它們可能不會直接解決你的問題。我遇到的眾多難題促使我撰寫了這本書——我從之前的錯誤和努力工作中學到了很多，所以你也應該這樣！從頭開始養成好習慣，將會讓你更富有成效和快樂。

非目標讀者

遺憾的是，本書并不是適合所有的人。如果你有興趣學習JavaScript，建議先從其它地方學習一些該語言的基本知識，然后再回到本書。如果你已經能夠編寫整潔、零bug的代碼，且這些代碼有充分的文檔和注釋，能夠自動化構建、且連續運行所有單元測試和集成測試、能夠生成完整的代碼覆蓋率（code coverage）報告、自動部署到生成環境，這樣的話，本書對你可能就沒多大用途了。如果不得不進行代碼調試的話，可以快速看一下第7章，或者可以看一下第6章，了解一些小技巧。

如果你不經常用JavaScript，現在就可以合上本書了。

內容簡介

本書將在幾個步驟內解決如何編寫可測試的代碼。首先，我們將研究復雜度（complexity）。接著看架構選擇，其會限制復雜度和耦合度（coupling）。以此作為基礎，在功能層面和應用程序層面上繼續測試方面的內容。我們將全面了解代碼覆蓋率和調試（debugging），然后完成自動化相關的所有內容。在本書最后，大家將更全面理解“什么是”以及“如何進行”可測試的JavaScript。

第1章可測試的JavaScript

本書的最重要主題是編寫和維護“可測試”的代碼。但可測試的代碼是什么？為什么要努力編寫它？如何進行編寫？我們將從研究這些問題開始，并且了解一些流行的開發理論以及它們和可測試代碼之間有何聯系。最后，不管是是否跟著進行實戰，編寫可測試代碼的關鍵都在于讓代碼保持短小、整潔、簡單、松耦合。

第2章復雜度

復雜度是很多問題的根源，不僅僅是可測試性。這些問題包括可理解性和可維護性，這兩個因素是代碼質量的關鍵指標。一些系統和應用程序本質上是復雜的，事實上，大多數應用程序都是很復雜的，但在處理和表達這些復雜性時，有正確的方式也有錯誤的方式。很顯然，將復雜的部分分解成一個個更小、更簡單的小塊是首要步驟。降低耦合度和扇出（fan-out）是管理復雜度的另外兩種方式。在探索可測試的JavaScript時，我們會研究所有這些方法，甚至更多內容。

第3章基于事件的架構

討論復雜度之后，我們將深入研究基于事件的架構。該應用程序架構可以極大地降低復雜度和耦合度，同時提供簡單的方式將應用程序分解成更小、更自足的片段。不管應用程序是用于服務器端還是客戶端，或者（很可能）用于兩者，基于事件的架構均可以解決第2章中列舉的很多問題。即便該架構不適合作為所有應用程序的總體架構，在整體架構中肯定也會有用到基于事件架構的概念和實踐的地方。

第4章單元測試

關于單元測試有很多爭論。測試到底有多重要？單元測試并不能發現所有的錯誤。像其他工具一樣，單元測試是可測試性的其中一部分。描述代碼為“可測試”的，并不意味著這些代碼的測試用例是可用的；而是說為這些代碼編寫測試用例比較簡單而已。單元測試是特殊的測試，因為通常它們是測試開發人員唯一要編寫的。它們具有侵入性，要求測試代碼和程序代碼隔離，并且可以獨立于應用程序運行。這可能會使單元測試變得有難度，因為在隔離環境下獨立運行測試代碼是非常困難的。本書很大一部分章節都是講解如何確保代碼能夠隔離運行，從而使編寫單元測試變得更簡單。單元測試無法發現所有的Bug（甚至大多數bug），但它們所找到的Bug驗證了運行單元測試確實是值得的。同樣重要的是，測試代碼要遵循和即將測試的應用程序代碼一樣的高標準和高原則。

第5章代碼覆蓋率

代碼覆蓋率通常與單元測試有關。代碼覆蓋率是單元測試的一個很好的衡量標準；然而，我們會發現這并非總是如此。代碼覆蓋率不僅僅適用于單元測試！所有類型的測試，包括集成測試、手工測試、性能測試，都可以受益于代碼覆蓋率。我們將研究代碼覆蓋率的優勢和劣勢，以及如何生成、查看代碼覆蓋率、并使其變得有意義。

第6章集成測試、性能測試、負載測試

當然，除了單元測試以外，還有很多其他類型的測試。集成測試、手工測試、性能測試、功能測試以及其他類型的測試，在尋找和挖掘Bug的工作中，都發揮著很重要的作用。不管誰做這些測試工作——開發人員、QA團隊，甚或是不知情的用戶，不管你喜歡不喜歡，都要完成這些類型的測試。將應用程序作為一個整體進行輕松測試的能力也是至關重要的。模塊化功能使測試代碼能夠與實現的功能更密切相關，這有助于開發人員更快地修復bug。在這些測試中使用代碼覆蓋可以快速顯示黑盒測試期間執行的代碼。大量的基于JavaScript的工具可以讓開發人員用于集成測試和性能測試，我們將深入研究其中一些工具，給大家一個直觀的展現。

第7章調試

我們編寫的代碼，第一次編寫時不管看起來多完美，都是不完美的。我們的代碼肯定會產生Bug，可能有很多的Bug。我們想到的和意想不到的Bug都有可能會破壞代碼。我們的測試、其他人的測試、或者用戶使用程序時都有可能發現Bug。測試時發現的Bug是最容易解決的，這也是最大化測試的一個很好的理由。用戶運行程序時發現的Bug更難以追蹤，其結果是，不僅要調試自己的代碼，還得調試別人的代碼。針對Node.js和瀏覽器代碼這兩方面，我將分享一些調試的技巧和竅門。要準備一個好用的調試環境，因為我們要經常用到它。

第8章自動化

最后，對于測試，一遍遍地手工操作不僅不可持續，而且非常無趣。軟件編程是世界上手工處理過程最多的工作之一，但測試和軟件維護卻不一定。運行測試、生成代碼覆蓋率報告、執行靜態分析、精簡和壓縮代碼、以及向生產環境或其他環境上部署或回滾代碼都應該是自動化過程的一部分。自動化可以確保不管發生什么情況，無論是成功還是失敗，它會很快地進行處理，更重要的是在某種程度上可以重復操作。程序代碼錯了，自動化測試就會失敗、生產環境運行也會失敗、其他事情也會出錯，但這些絕對不會關聯到我們的程序代碼。這就是現實。關鍵是要從這些失敗（連同你造成的故障）中盡快且不著痕跡地恢復回來。

小結

編寫可測試的代碼會讓我們的工作，以及我們手下那些人的工作，變得非常簡單。從更少的Bug到更多容易修復的Bug、從容易測試到簡單調試，編寫可測試的JavaScript是明智之選。

本書將展示通往睿智道路的途徑。閱讀整本書之后，大家將對編寫和維護可測試的JavaScript實際需要方面有一個很好的了解。但這僅僅是一個開始。我們作為開發人員，必須將這些實踐和模式應用到日常工作中。必須抵制住“懶惰”且不編寫測試的誘惑，避免走回頭路，防止自己或別人來收拾我們的爛攤子。可測試的JavaScript代碼將會延續。如果你現在正在編寫遺留代碼，幫你自己和老板一個忙，開始編寫可測試的代碼。希望你會發現，這樣做并不是很難，而且非常有益、甚至非常有趣！