TDD的背景

　　自從03年Beck正式提出（事實(shí)上在00年，Beck提出eXtreme Programming時(shí)，就已經(jīng)提出了這個(gè)詞）Test-driven design/development這樣一個(gè)基于測試優(yōu)先、重構(gòu)和迭代的革命性的開發(fā)方法以來，無數(shù)的實(shí)踐已經(jīng)證明，對于適合進(jìn)行TDD的領(lǐng)域，TDD能夠極大地提高代碼的可維護(hù)性和開發(fā)效率。

　　在這樣一個(gè)迭代的流程中，在寫任何的production code之前，先寫test，再寫production code，并且不斷地對代碼進(jìn)行清理和重構(gòu)，并且每次迭代都要進(jìn)行回歸測試，保證新增的test和production code不會break任何已有的test和production代碼。

　　一般來講，支持自動化的回歸測試的工具相對比較容易實(shí)現(xiàn)。整個(gè)流程中的難點(diǎn)在于：當(dāng)先行寫test代碼的時(shí)候，必然要求先定義被測試的production code的外部接口，對于第一次迭代，自然沒有問題；但是，由于需求的變更，或者整體設(shè)計(jì)的變更，在后續(xù)的迭代過程中，經(jīng)常會發(fā)生，已有的已經(jīng)實(shí)現(xiàn)并且包含完整測試的production code的外部接口需要變更或者說重構(gòu)；盡管從理論上，絕大多數(shù)的重構(gòu)需求，都有規(guī)律甚至是模式可循，但是，如果完全依賴于人工操作，則不僅效率不高，且極易出錯(cuò)。所以，但凡成功的TDD實(shí)踐，其中都不乏很多支持重構(gòu)的工具。比如，現(xiàn)行絕大多數(shù)的集成開發(fā)環(huán)境，都有很多自動化的代碼重構(gòu)工具，大大的降低了代碼重構(gòu)的成本。

　　但是還有一些領(lǐng)域，TDD還略微有些力不從心，或者說，至少，至今沒有看到太多比較好的實(shí)踐案例。比如：對于Database和UI。

　　對于數(shù)據(jù)庫開發(fā)的TDD，到目前為止面臨的主要挑戰(zhàn)是工具的支持。無論是自動化的回歸測試工具，還是重構(gòu)工具都還遠(yuǎn)遠(yuǎn)不夠成熟。

　　而對于UI的TDD，則是本文的主題。

　　TDD in HTML & JavaScript 概述

　　談到應(yīng)用程序的UI，其實(shí)包括兩個(gè)方面的內(nèi)容：一方面是純圖形的look & feel；另一方面，則是用戶和應(yīng)用程序的交互。用戶和應(yīng)用程序的交互往往同時(shí)導(dǎo)致圖形界面的變化，并且，轉(zhuǎn)換到新的交互行為。

　　由于工作實(shí)踐中主要是基于WEB的HTML和JavaScript的項(xiàng)目，這里對TDD in UI的討論，將focus在基于HTML和JavaScript的UI。

　　同時(shí)，一般來講，WEB程序的表現(xiàn)層主要有客戶端代碼和服務(wù)端代碼，而服務(wù)端代碼，相對來說，更容易被測試。所以，本文討論的重點(diǎn)，主要focus在客戶端代碼。換句話說，這里討論的TDD in HTML & JavaScript指的是對于客戶端的HTML和JavaScript的TDD。

　　TDD in HTML & JavaScript 之可行性

　　說到可行性，其實(shí)可以分兩個(gè)層面：理論上的可行性，和實(shí)際應(yīng)用的可行性。

　　第一個(gè)問題是：純圖形的look & feel理論上可以進(jìn)行自動化的測試嗎？答案幾乎是否定的。因此，主要用于呈現(xiàn)純圖形的HTML及CSS，也幾乎是很難自動化測試的。

　　那么，用戶和應(yīng)用程序的交互理論上是否可以進(jìn)行自動化測試呢？答案毫無疑問是肯定的。

　　WEB交互的測試其實(shí)可以根據(jù)WEB程序的架構(gòu)，分為兩種類型：

1. 傳統(tǒng)的WEB程序主要基于服務(wù)端來呈現(xiàn)內(nèi)容，用戶和頁面的交互，主要是get，post數(shù)據(jù)和頁面跳轉(zhuǎn)。因此，對應(yīng)的測試方式，主要也是由測試工具模擬需要get或post的數(shù)據(jù)，并且跟蹤期望的頁面跳轉(zhuǎn)情況。這種情況下的測試其實(shí)相對簡單，因此本文不想過多討論。
2. 當(dāng)前的基于AJAX的WEB程序則很大程度上豐富了用戶和頁面交互的方式，用戶和頁面的交互，除了傳統(tǒng)的get，post數(shù)據(jù)和頁面跳轉(zhuǎn)，在頁面不刷新的情況下，還通過觸發(fā)各種DOM事件，甚至直接觸發(fā)JavaScript方法的執(zhí)行，由JavaScript來改變和呈現(xiàn)內(nèi)容。此時(shí)，傳統(tǒng)的只能模擬需要get或post的數(shù)據(jù)的測試工具就無能為力了。此時(shí)由于所有的邏輯代碼都在JavaScript中，所以，本質(zhì)上其實(shí)是需要對大量的JavaScript代碼進(jìn)行測試。此正是本文希望討論的重點(diǎn)。

　　首先，針對JavaScript的自動化測試工具其實(shí)已經(jīng)有不少了，如：

• JsUnitTest
• QUnit

　　Mock工具也有：

• jqMock
• JSMock

　　支持直接重構(gòu)JavaScript代碼的工具相對比較少，提供的功能也都還非常弱：

• IntelliJ IDEA
• Eclipse

　　從支持工具的現(xiàn)狀，可以說，影響TDD in JavaScript的實(shí)際可行性的因素之一是重構(gòu)工具的缺乏。不過，最近的情況有了一些改變，現(xiàn)在也出現(xiàn)了一些支持JavaScript重構(gòu)的變通的解決方案，如：

• Script# - Write C# code，compile C# source code directly to JavaScript code
• jsc – Write any .NET code, convert .NET assembly to JavaScript, ActionScript, Java or php code

　　這些方案的特點(diǎn)是，利用現(xiàn)有的IDE對流行的編程語言如C#源代碼的完善的coding，尤其是強(qiáng)類型，重構(gòu)和測試的支持，讓開發(fā)人員寫C#，由工具轉(zhuǎn)換為可直接執(zhí)行的，格式化的JavaScript代碼。除了充分利用IDE對流行語言的coding支持之外，這類方案的另一個(gè)好處是，相對于高薪聘請Senior的JavaScript開發(fā)人員，Junior的C#的開發(fā)人員要便宜得多，也易招得多，但得益于Script#，已經(jīng)足夠能用他們熟悉的C#，寫出邏輯復(fù)雜和OO的JavaScript代碼，因此，開發(fā)成本被大大降低。

　　綜上所述，TDD in JavaScript不僅理論上是可行，實(shí)際應(yīng)用上，也是有足夠的工具支持的。尤其是如Script#這樣的工具的出現(xiàn)，極大地提高了JavaScript代碼的開發(fā)效率。

　　TDD in JavaScript 之最佳實(shí)踐

　　誰都希望能有最佳實(shí)踐。什么是最佳實(shí)踐呢？有很多人見不得“best”，“最”這樣的詞，認(rèn)為，這個(gè)世界上沒有“最”的東西。有嗎？當(dāng)然有！我們首先要略為上升到哲學(xué)的高度，對于包含“最”這樣的詞匯的命題，如果想要為“真命題”，則必然是需要加上一個(gè)適當(dāng)?shù)那疤釛l件的。

　　比如說：我說“我是這世界上最NB的人”。這毫無疑問是個(gè)假命題。因?yàn)椋狈m當(dāng)?shù)那疤釛l件。你可以自己做個(gè)練習(xí)，如果覺得這個(gè)命題假，想辦法給它加上更多的前提條件，一定能讓它變真。

　　所以，所謂最佳實(shí)踐，指的是，對一個(gè)或者一類特定的問題，在一個(gè)相對確定的背景下，所能采取的實(shí)際處理的方案典范。加上前提條件，則“最佳實(shí)踐”當(dāng)然是存在的，也是值得討論的。

　　通過前面的章節(jié)，我們已經(jīng)把本文重點(diǎn)討論的主題，限制到一個(gè)相對小的范圍，那就是對基于AJAX的WEB應(yīng)用程序中的大量的JavaScript代碼，如何進(jìn)行TDD？

　　并且，我們也收集了足夠的支持TDD需要的各種工具，包括自動化測試工具，Mock工具和重構(gòu)工具。在這些工具的支持下，很大程度上，WEB程序客戶端JavaScript代碼的TDD和服務(wù)端代碼的TDD，不應(yīng)該有很大的區(qū)別。但同時(shí)，由于客戶端代碼的特殊性，自然也應(yīng)該有一些客戶端腳本代碼所特有的實(shí)踐模式。

　　以下首先列出本人推薦的一些實(shí)踐模式，希望大家能一起修正和補(bǔ)缺。

　　最佳實(shí)踐一：應(yīng)用MVC模式

　　在傳統(tǒng)的非AJAX的WEB程序中，JavaScript往往處于非常輔助性的地位。除了實(shí)現(xiàn)一些特效和數(shù)據(jù)驗(yàn)證等輔助功能之外，一個(gè)頁面的JavaScript代碼，恐怕屈指可數(shù)，自然無所謂測試，甚至是TDD了。

　　但是在現(xiàn)在的復(fù)雜的AJAX應(yīng)用中，以往必須由多個(gè)獨(dú)立頁面的get，post和頁面跳轉(zhuǎn)才能組合實(shí)現(xiàn)的功能，通過JavaScript，可以在一個(gè)無需刷新瀏覽器的頁面中，輕易實(shí)現(xiàn)，不但用戶體驗(yàn)更佳，速度更快，對服務(wù)器的負(fù)擔(dān)也更小。

　　此時(shí)，原本傳統(tǒng)WEB程序的服務(wù)端需要處理的問題，如數(shù)據(jù)綁定，事件綁定，邏輯控制等，需要在客戶端進(jìn)行處理。也因此，原本為了解決WEB程序服務(wù)端代碼可測試性問題MVC模式，也就一樣可以良好的應(yīng)用于客戶端。清晰的將JavaScript代碼分割成M，V，C，將能夠把相同的邏輯職責(zé)盡可能集中到一起來管理，從而極大地增加客戶端代碼的可維護(hù)性和可測試性。

　　下表簡單對比服務(wù)端和客戶端MVC下M，V，C的對應(yīng)職責(zé)：

　　最佳實(shí)踐二：應(yīng)用依賴注入和IoC容器

　　應(yīng)用MVC模式，本質(zhì)上是抽象的邏輯職責(zé)上的解耦。而依賴注入和IoC容器則是代碼的物理依賴性上的解耦。盡可能的利用構(gòu)造器注入，設(shè)值注入，接口注入或IoC容器來解除具體的實(shí)現(xiàn)類之間的直接依賴，自然就能極大的大提高每個(gè)具體的實(shí)現(xiàn)類的可測試性。

　　最佳實(shí)踐三：應(yīng)用模板引擎呈現(xiàn)主體內(nèi)容

　　AJAX應(yīng)用中的一個(gè)需要客戶端呈現(xiàn)的View，必然需要呈現(xiàn)一些HTML，這些HTML往往需要根據(jù)Model返回的JSON數(shù)據(jù)動態(tài)構(gòu)造。一般來講，我們會有三種方式來構(gòu)造和呈現(xiàn)這些HTML：

• 在JavaScript中遍歷JSON數(shù)據(jù)，拼接HTML字符串，呈現(xiàn)到頁面上；
• 在JavaScript中遍歷JSON數(shù)據(jù)，動態(tài)實(shí)例化DOM對象，通過DOM對象的方法，呈現(xiàn)HTML的DOM；
• 通過如JTemplate這樣的JavaScript模板引擎，將JSON數(shù)據(jù)綁定到一個(gè)HTML模板，由模板引擎呈現(xiàn)最終的HTML；

　　本最佳實(shí)踐的建議內(nèi)容就是，對于一個(gè)View的主體內(nèi)容，應(yīng)該盡可能的通過模板引擎來呈現(xiàn)。為什么呢？因?yàn)椋瑢τ谝粋€(gè)WEB程序來說，最不穩(wěn)定的，會經(jīng)常變化的部分，無疑是純圖形的HTML和CSS，使用模板引擎，將能夠使得這些HTML盡可能的集中，并且易于修改，也更易于HTML和JavaScript的整合。

　　最佳實(shí)踐四：應(yīng)用Script#

　　應(yīng)用Script#好處前面已經(jīng)提過了，這里再簡單列舉一下：

• 充分利用現(xiàn)有的IDE對流行的編程語言如C#源代碼的完善的coding，尤其是強(qiáng)類型，重構(gòu)和測試的支持；
• 相對于高薪聘請Senior的JavaScript開發(fā)人員，Junior的 C#的開發(fā)人員要便宜得多；

　　如反對，請列舉我不該用它的理由？

　　對于以上幾個(gè)最佳實(shí)踐的應(yīng)用實(shí)例，請參見我之前的文章：This is jqMVC# – CNBLOGS Google Tracer Sample。

it知識庫：討論: TDD in HTML & JavaScript 之可行性和最佳實(shí)踐，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。