新書《編寫可測試的JavaScript代碼 》出版，感謝支持

本書介紹

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代碼將會延續。若是你如今正在編寫遺留代碼，幫你本身和老闆一個忙，開始編寫可測試的代碼。但願你會發現，這樣作並非很難，並且很是有益、甚至很是有趣！