相信對敏捷熟悉的朋友對測試驅動開發（TDD）的概念都不會陌生。測試驅動開發強調通過預定義的測試標準驅動開發寫出符合標準的代碼。不過現在越來越多人會把TDD等同于單元測試驅動開發，即UTDD。我并不否認UTDD的價值，不過我更想強調應該把TDD當作一種思維。TDD的思維其實非常合理，做任何事情都應該有一個預期的目標和標準，如果目標和標準不清晰，就很難確保產出的價值。

“The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. After I’d written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, “Of course. How else could you program?” Therefore I refer to my role as ‘rediscovering’ TDD.”

—Kent Beck, re-discoverer and namer of Test-Driven Development

從Kent Beck的表述來看，TDD最初也更像是一種思維，并且應該是理所當然的做事方式。

回到研發工作當中，測試驅動開發可以在很多環節里體現，同樣，我們也可以主觀地把TDD的思維運用到各個環節當中去。例如：

契約測試

契約測試是期望消費者和提供者之間基于預先定義的契約進行協作的實踐。所以我們可以認為契約測試符合測試驅動開發的思維，這樣的協作過程規范了寫作標準，避免了傳統的口頭或文檔承諾帶來的交付結果與預期不匹配的問題。

需求驗收標準

在敏捷團隊中教練會經常強調驗收標準的重要性，而實際上驗收標準對任何一個團隊都不可忽略。驗收標準在需求梳理過程中，迭代計劃階段都成為團隊參考的重要依據。而在Thoughtworks推行的實踐中，“開卡”也是把驗收標準的價值進一步延伸的實踐。

“開卡”的做法是在具體的開發人員準備開發某一個用戶故事之前，需要基于自己對需求的理解并結合驗收標準向產品、測試以及相關人員講述對需求的理解。通過這種方式對齊需求驗收標準，降低功能開發產生偏差的風險，同時也是質量內建的有力措施。當然，除了開卡之外，還有行為驅動開發（BDD）等實踐都是把驗收標準與研發過程有效結合的實踐。而類似的實踐都符合測試驅動開發的思維。

標準驅動

通過以上的實踐我們能理解測試驅動開發的思維，會強調先有參考標準，再基于標準去實現交付。自然我們也可以把這種思維進一步擴展到更多的層面，比如通過預定義的標準驅動團隊的行為。而在現實情況下卻也并不容易。

不管哪種場景下，遇到的第一個問題就是如何制定標準、如何確保達成共識的標準、標準如何保持更新。

很多團隊對標準的第一印象往往是固化了大家的行為，對團隊要求又提高了，推廣時阻礙太多等等。而基于這些擔心和固有印象一直守著原有的工作模式不想改變。

第二個關鍵點則是如何驅動。標準驅動在有了標準之后面對的就是如何產生驅動力的問題。我也見過太多的團隊標準都是有的，卻發現總是不能按照標準執行。有人說標準不適合自己，有人說標準太多影響現有工作，也有人說標準增加了工作復雜性。所以，往往在標準沒有執行之前就被否定了。而讓團隊愿意依據標準執行無非從兩個角度入手：

第一是標準要與團隊甚至個人痛點相結合；

第二是標注的產出要獲得團隊的共識和認可。

回到本文主題上，測試驅動開發的運用是在理解測試驅動開發思維的前提下，找到適合的場景運用適合的實踐的過程。從我們比較熟知的UTDD到ATDD，再到BDD以及本文延伸出的很多觀點，都不是對所有團隊通用的。與敏捷本身類似，思維永遠是實踐的基礎！