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

　　真相其實(shí)是，測(cè)試驅(qū)動(dòng)開發(fā)真TMD太痛苦了。寫那些沒完沒了的測(cè)試需要很強(qiáng)的自律，遠(yuǎn)不是你想象的那么簡(jiǎn)單容易。

　　但你知道什么更讓人討厭嗎？是缺少這些測(cè)試而出現(xiàn)的麻煩。

　　讓我澄清一下。我并不是想來勸說你去實(shí)施測(cè)試驅(qū)動(dòng)開發(fā)。我想做的只是要給你一個(gè)真實(shí)的認(rèn)識(shí)，讓你明白TDD是如何工作的，以及你能從中得到哪些好處。

　　對(duì)軟件開發(fā)來說，我基本上把測(cè)試驅(qū)動(dòng)開發(fā)當(dāng)做一種保險(xiǎn)。它能保證你的軟件有一個(gè)預(yù)設(shè)的質(zhì)量關(guān)卡，大多數(shù)是依據(jù)bug的數(shù)量和軟件變更的風(fēng)險(xiǎn)度來判定。它同時(shí)能降低萬(wàn)一你的主要開發(fā)人員被車撞后造成的損失，以及你的軟件所依賴的平臺(tái)上的API遭遇類似事件所帶來的危害。

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

　　在Transloadit公司，我們 100%的代碼都是由測(cè)試驅(qū)動(dòng)開發(fā)的。我們這樣做的主要原因是我們的系統(tǒng)用了node.js，這種技術(shù)目前來看在某種程度上仍然是有很高的風(fēng)險(xiǎn)的技術(shù)，也許這正是我們最大的麻煩，但同時(shí)也是我們最大的優(yōu)勢(shì)所在。另外一個(gè)很大的風(fēng)險(xiǎn)是我們使用的第三方工具包，例如ffmpeg和image magick，這些東西在升級(jí)時(shí)出奇的危險(xiǎn)，因?yàn)樗鼈儎?dòng)不動(dòng)就改變API和接口運(yùn)行方式。而最后一個(gè)，但絕對(duì)不是最不重要的一個(gè)，是我們的某些東西太復(fù)雜了。

　　現(xiàn)在，讓我解釋一下我們?nèi)绾卫脺y(cè)試驅(qū)動(dòng)開發(fā)來避免這些風(fēng)險(xiǎn)的。首先，在開發(fā)所有的新功能前先寫系統(tǒng)測(cè)試。所有的系統(tǒng)測(cè)試都是利用整套的REST service，它產(chǎn)生真實(shí)的HTTP請(qǐng)求，評(píng)估響應(yīng)的信息，同時(shí)也檢查這個(gè)過程中產(chǎn)生的文件。我們通過文件的元數(shù)據(jù)信息來確認(rèn)文件，對(duì)于圖片我們使用特定的設(shè)計(jì)進(jìn)行可視化比較。對(duì)于視頻我們使用截屏圖像進(jìn)行可視化對(duì)比。

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

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

　　很顯然，在這個(gè)過程中你有很多機(jī)會(huì)去做傻事，或者迷失了原始方向。這時(shí)系統(tǒng)測(cè)試就來拯救你了。任何當(dāng)你不知道下一步該做什么的時(shí)候，只要運(yùn)行一下系統(tǒng)測(cè)試，它就會(huì)告訴你還少些什么要做。

　　完美的過程嗎？不，在我們的產(chǎn)品中的這里或那里，多少都會(huì)有些bug，但不多，我十個(gè)手指頭都能數(shù)過來。上周末，我們對(duì)我們的產(chǎn)品做了一個(gè)瘋狂的改動(dòng)：我們把底層的MySQL驅(qū)動(dòng)(我們用的是php，別問我怎么做的)換成了node-mysql。我們已經(jīng)在node-mysql上工作了，同樣使用的是TDD-masochism，升級(jí)相當(dāng)?shù)钠椒€(wěn)(目前為止)。這種成績(jī)對(duì)于一個(gè)牽涉有6000行代碼的改動(dòng)來說很不錯(cuò)了。

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

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

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

it知識(shí)庫(kù)：我們的測(cè)試驅(qū)動(dòng)開發(fā)經(jīng)驗(yàn)，轉(zhuǎn)載需保留來源！

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