《編寫可測試的JavaScript代碼》——導讀

前言

編寫可測試的javascript代碼

既然要對代碼進行測試，那麼為什麼不讓這一過程變得盡可能簡單和輕松呢？javascript用戶端代碼測試之是以尤其困難，是因為我們幾乎無法控制代碼運作的環境。多種類型的作業系統、多個版本的作業系統、多種類型的浏覽器、多個版本的浏覽器，更不用說插件、擴充、多語言版本和縮放大小了，還有一些未知内容，所有這些因素交織在一起，阻礙着應用程式的性能。這些因素會導緻程式變慢、中斷、崩潰，最終覆滅。這裡面的内容紛繁複雜！服務端javascript給了我們更多的控制權，以便我們能夠從總體上控制執行環境。然而，rhino和node.js應用程式不像其他語言一樣有完整的成熟工具、測試程式以及生态系統。此外，node.js的異步特性也使得測試變得更加複雜。有趣的是，這樣一種與異步執行密切相關的語言，竟然沒有設定與該執行模式相配的内置支援。

無論如何，測試——尤其是javascript測試——是很複雜的。克服這種複雜性的最好辦法是完全控制自己實際所控制的東西：代碼。代碼是連續存在的，一方面是從别人的代碼到自己的代碼，另一方面是從遺留代碼到非遺留代碼。

什麼是遺留代碼（legacy code）？我比較推崇michael feathers在他的優秀作品working effectively with legacy code（prentice hall出版社）中的定義：遺留代碼是沒有測試過的代碼，這段代碼将無法存活或永遠不會被任何人接觸到。再次接觸遺留代碼時，就是要重寫它了。看一下目前的項目，任何沒有被測試的代碼都有可能會被重寫。重寫的人可能不是原作者，而是負責處理這個任務（增強代碼或修補漏洞）的人。除非這些代碼經過測試，否則它們就是必須要重寫的無用代碼。這段代碼可能很驚人，但它唯一能存活的方法就是永遠不會産生bug，并且沒有人要求對它進行增強或者添加新特性。即便如此，你願意将這些未經測試的産品代碼推到市場上嗎？即使代碼之前“能用”，之後你還能繼續滿意嗎？擁有該代碼的公司也是同樣滿意嗎？是以，通常的結果都是付費重寫。公司不得不再次付費進行代碼重寫，這真是太糟糕了，但這就是遺留代碼的情況。

[第1章 可測試的javascript

<a href="https://yq.aliyun.com/articles/91989">1.2　代碼是讓人用的</a>

<a href="https://yq.aliyun.com/articles/91992">1.3　卓越的應用程式代碼</a>

<a href="https://yq.aliyun.com/articles/91994">1.4　小結</a>

第2章 複雜度

第3章 基于事件的架構

第4章 單元測試

第5章 代碼覆寫率

第6章 內建測試、性能測試、負載測試

第7章 調試

第8章 自動化