在上一篇文章《讓我們再聊聊TDD》里面，通過對DHH的文章以及DHH和Kent Beck等討論的分析，我闡述了對TDD的理解和分類，現在來繼續聊聊TDD的實施和分層。

現在還有非常多的軟件工程師在質疑TDD的可行性，比如太難不會、成本太高無法推動、意義不是很大等，但是他們卻一直都在做著TDD，只不過沒有意識到而已，這便是“不識廬山真面目，只緣身在此山中”。

[[185630]]

TDD的實施一般分為思維層面和技術層面。一般來說，思維層面上的實施成本較低、容易接受，但是缺點很多，比如難以傳遞、難以持續獲得快速反饋等;而技術層面上的實施一般成本較高、不容易被人接受，但是優點更多，比如可以獲得快速反饋、更容易傳遞和協作等。而現實世界中TDD的實施一般分為三個階段，即無意識的TDD、被動通過技術實現的TDD、以及有意識和主動通過技術實現的TDD。

1. ***階段：無意識的TDD

對于軟件開發人員，當他們拿到一個新的軟件需求時，首先會思考如何實現，其中包括當前軟件架構、業務分解、實現設計、代碼分層、代碼實現等。然后通過思考和設計所得到的產出物來驅動代碼實現，進而在代碼實現中會思考如何通過一個或多個函數或者算法來實現業務邏輯。所以軟件系統的實現要先通過意識層面的思考，再進行技術層面的工作。

當開發人員思考和設計這些函數或者方法的時候，一般都會思考它們有哪些參數，然后想象將這些參數換成真實的數據后傳遞進去，會得到怎樣的返回值。好一點的開發人員會思考如何處理異常輸入和異常返回值。

這類思考其實已經是意識思維上的TDD，它幫助開發人員先在大腦里面設計并驗證代碼實現，甚至幫助其重構代碼。所以很多開發人員都在無意識的情況下做著TDD。

比如在一個銀行系統里面，開發人員拿到一個需求，需要開發一個通過手機APP轉賬的功能。

首先開發人員會基于當前的軟件架構思考：是開發一個全新的模塊來處理這個業務?還是基于當前架構中的某個模塊來添加代碼進行處理?

當確定架構和設計之后，就開始思考具體的代碼實現，比如類的設計、方法的設計或者函數的設計等。當開發“將錢從原帳號轉出”這個功能前，開發人員會思考：這個功能需要支持當錢從原帳號中轉出成功后，原帳號中的余額等于原始余額減去轉出金額。進一步有些程序員還會設計一些用來驗證功能的實例，比如帳號中的原始余額是999.99，轉出111.11，那么剩余的金額就應該是888.88。

在這樣思考之后，開發人員便開始根據自己大腦中的測試邏輯和用例來驅動和輔助開發過程。在代碼開發完畢之后還會想一些辦法來驗證一下所實現的功能是否符合預期，比如人工使用之前的或者新的測試用例再測試一下。如果驗證正確，就會認為自己開發的功能正確了，并交給測試人員進行測試。

其實開發人員在開發前思考測試邏輯和用例的過程就是在做TDD了。

很多做業務分析的BA和測試分析前移的QA也同樣在無意識的做著TDD(注：在前一篇文章中已說明TDD包含ATDD)，比如分析驗收條件、寫出驗收文檔等。只不過這些AC和驗收文檔可能寫得不是很明確或者不是很好，比如不是實例化需求等，但是本質上已經是TDD了。

只不過是初級的無意識的TDD，可能有的人做得好，有的人做得不好，而且沒有明確的產出來協助和規范這個測試驅動開發方式，也缺乏快速反饋、度量、傳遞和協作等。因此從無意識到有意識將是做好TDD的一個重要過渡。

2. 第二階段：被動通過技術實現TDD

當有一部分軟件工程師意識到了TDD的意義和普遍存在性之后，就開始準備解決思維上的TDD的缺點。而解決這些問題的方法就是在技術層面上用代碼來實現TDD，用明確的代碼來協助和規范開發人員的測試驅動開發行為，來度量他對業務邏輯以及代碼實現的理解度。通過將他的理解傳遞給以后的維護人員，讓他的理解能重復被使用，以及和其他人協作開發。

但是現實中很多開發人員的認識不足以及技術能力不夠，就算管理層支持并且主動推動TDD，最終

由于開發人員設計和選取的測試用例合理性很差，導致驅動出來的代碼有效性差，測試用例無法體現出SBE(Specification by example)導致易讀性差，對于自動化測試框架和測試編寫不熟悉導致開發速度很慢等，往往是被動的在技術層面上去實現TDD，所以出現了各種怨言，各種抵觸，進而導致技術層面上的TDD很難以大規模實施。

由于意識層面上的難易程度和工作量都比技術層面上相對較小，所以前者實施起來相對容易一些，而后者則相對較難，所以如果通過了各種手段強行實施TDD，而沒有主動去擺正做TDD的意識，甚至沒有足夠的技術能力，那么這樣的TDD就是一個倒三角，非常容易倒塌。

TDD倒三角

所以，如果不希望技術層面上的TDD隨時倒塌，就需要把這個倒三角補全，才能更好的、長久的實施TDD。

3. 第三階段：有意識和主動通過技術實現TDD

為了大規模以及有效的實施TDD，首先要突破思維意識的局限，認識到TDD的普遍存在性和適用性，不要害怕和排斥TDD這種思維和開發模式。

其次要主動學習，并刻意練習TDD的技術實現，提升自己的技術能力，從而在技術層面能更容易的實現TDD，擺脫被動TDD的困境。其中學習的方法包括閱讀TDD相關的書籍和文章，書籍包括《測試驅動開發》、《重構》、《BDD In Action》以及《系統思考》等，從而充分理解TDD優點和局限。

對于刻意練習，一定要長時間堅持去做，讓其成為一種習慣。如果在項目中沒有合適的環境去練習，還可以通過一些第三方的TDD練習系統去做刻意練習，比如Cyber-dojo。只有大量的刻意練習才能讓你在真實的代碼編寫過程中去思考和理解TDD，去運用你通過學習得到的知識，最終才能做到有意識和主動的通過技術去實現TDD，TDD的倒三角才能變成一個穩定的磚塊，然后哪里需要往哪里搬。

TDD磚塊

4. 總結

綜上，大部分開發人員都應該在做TDD，只不過他們是無意識的或者被動的去實現的，只有少部分是有意識和主動的去實現的。

既然人人都在做TDD，那么我們為什么不能和黑客帝國里面的Neo一樣選擇紅色藥丸來認清楚現實，主動擁抱TDD，并通過大量的刻意練習去改變自己的工作習慣，讓TDD成為自己工作習慣的一部分，這樣才能更好的提升軟件質量，大大降低軟件維護成本。不管你信不信，反正我信了。