你應該聽過或讀過不少關于測試驅動開發的討論，測試驅動開發往往被比喻為神奇的獨角獸，它能幫你照看你的軟件，讓大家樂得其所。于是，在寫了18.000行“神奇獨角獸”代碼后，我想把我們的體驗從整體的角度闡述一下。

　　真相其實是，測試驅動開發真TMD太痛苦了。寫那些沒完沒了的測試需要很強的自律，遠不是你想象的那么簡單容易。

　　但你知道什么更讓人討厭嗎？是缺少這些測試而出現的麻煩。

　　讓我澄清一下。我并不是想來勸說你去實施測試驅動開發。我想做的只是要給你一個真實的認識，讓你明白TDD是如何工作的，以及你能從中得到哪些好處。

　　對軟件開發來說，我基本上把測試驅動開發當做一種保險。它能保證你的軟件有一個預設的質量關卡，大多數是依據bug的數量和軟件變更的風險度來判定。它同時能降低萬一你的主要開發人員被車撞后造成的損失，以及你的軟件所依賴的平臺上的API遭遇類似事件所帶來的危害。

　　然而，在我們所生活的這個星球上，仍然有成百萬的人每天過著沒有保險的生活，很顯然，達到目的的方式并不是只有一條途徑。這完全依賴于你的責任心和你能或你想怎么去做事情。

　　在Transloadit公司，我們 100%的代碼都是由測試驅動開發的。我們這樣做的主要原因是我們的系統用了node.js，這種技術目前來看在某種程度上仍然是有很高的風險的技術，也許這正是我們最大的麻煩，但同時也是我們最大的優勢所在。另外一個很大的風險是我們使用的第三方工具包，例如ffmpeg和image magick，這些東西在升級時出奇的危險，因為它們動不動就改變API和接口運行方式。而最后一個，但絕對不是最不重要的一個，是我們的某些東西太復雜了。

　　現在，讓我解釋一下我們如何利用測試驅動開發來避免這些風險的。首先，在開發所有的新功能前先寫系統測試。所有的系統測試都是利用整套的REST service，它產生真實的HTTP請求，評估響應的信息，同時也檢查這個過程中產生的文件。我們通過文件的元數據信息來確認文件，對于圖片我們使用特定的設計進行可視化比較。對于視頻我們使用截屏圖像進行可視化對比。

　　一旦寫出來測試程序(也許是失敗的測試)，我們就開始寫單元測試。讓我來解釋一下我們所說的“單元“。對于我們來說，一個單元是我們能測試的一個最小粒度的功能片段。只要存在函數調用，類的創建，甚至閉包的回調，我們都會把它挑出來。所有的測試都是孤立的、分離的、能夠自動的運行處理。你可以想象的出，這部分工作是痛苦的，需要勇氣。

　　可是，產生的結果卻是不可否認的漂亮。寫這些測試感覺就像是在驗證數學理論。每一個步驟都是能夠分解的最小的邏輯單元。所有的步驟都是基于之前的一步。沒有必要每次都測試所有的 1 – 1000000個功能點，除非你有邏輯上的需求，需要一個特殊結果。

　　很顯然，在這個過程中你有很多機會去做傻事，或者迷失了原始方向。這時系統測試就來拯救你了。任何當你不知道下一步該做什么的時候，只要運行一下系統測試，它就會告訴你還少些什么要做。

　　完美的過程嗎？不，在我們的產品中的這里或那里，多少都會有些bug，但不多，我十個手指頭都能數過來。上周末，我們對我們的產品做了一個瘋狂的改動：我們把底層的MySQL驅動(我們用的是php，別問我怎么做的)換成了node-mysql。我們已經在node-mysql上工作了，同樣使用的是TDD-masochism，升級相當的平穩(目前為止)。這種成績對于一個牽涉有6000行代碼的改動來說很不錯了。

　　這就是我們做的。并不會由于我們使用了TDD，我們公司的產品就必然的優于我們的競爭對手。但我們承擔的風險要小的多，我們可以輕而易舉的做心臟手術。這給了我們分配資金的信心，給了我們能力去把剩余有限的資源(我們做事情步步為營)使用在新功能的開發上，而不是花在解決我們軟件里無處不在的缺陷上。

　　那么，TDD適合你嗎？這要視情況而定。按TDD模式寫程序需要很強的自律，獨角獸不會一直陪在你身旁讓你放心。想好了再去這樣做。有時一些系統測試程序會用掉你80%的努力來測試只是20%的工作。而有些情況會讓你把剩余的20%也搭上。我們很幸運能使用一種靈活的語言，我們大部分的接口都是使用的JSON。這使我們的測試成本更低。這些我們銘記在心。

　　[英文出處]：Test driven development at Transloadit

it知識庫：我們的測試驅動開發經驗，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。