序

我教計算機科學與軟件工程相關課程已經30年了，感覺很少有其他技術能像自動化單元測試（automated unit testing）這樣大幅影響我的教學（與研究）工作，在2001年短暫進入業界的那段時間，這種感覺尤其強烈。自動化單元測試是一套通用的方法，將這種方法與測試驅動開發（Test-Driven Development, TDD）理念相結合，可以令其更為明確地應用于多個領域。

我還記得自己當初是怎么突然之間就明白了TDD，其實那個時候并不是專門為了去理解TDD，而是在講授其他知識的時候想到了這個概念。那時我在講面向對象的開發，我把Martin Fowler寫的《UML精粹（第3版）》用作UML方面的參考書。Martin在那本書中討論了迭代式開發流程的三個關鍵做法，也就是自動化回歸測試（automated regression test）、重構（refactoring）與持續集成（Continuous Integration, CI）。我很認同這三種做法，而且很樂意鼓勵學生多寫一些代碼，去測試他們打算編寫的那些正式代碼，這樣就可以在一套用顏色來表示測試結果的界面之中立刻看到那些正式代碼是否能夠通過測試。

還有一個讓我頓悟的時刻，出現在大約10年之后，也就是2012年左右，那時我開始在Software Engineering Radio上面聽關于軟件架構的播客。我仔細閱讀了播客里面提到的某些參考資料，當時突然看到Robert C. Martin[也就是Uncle Bob（Bob大叔）]寫的Agile Software Development: Principles, Patterns, and Practices（《敏捷軟件開發：原則、模式與實踐》），里面有一小節（也就是4.2.2節）叫作“Serendipitous Architecture”（意外獲得的架構/偶得的架構）專門講了一個道理：如果你一開始就注意編寫那種可以接受測試的代碼，那么項目的架構就自然會變得比較合理，而且更加容易維護。

這兩次經歷讓我體會到了自動化測試是如何把流程與架構，以及功能性需求與非功能性需求結合起來的：這種測試讓我們能夠更加明確地了解自己寫出來的代碼在多大程度上滿足功能性的需求，同時，為了能夠在正式代碼中做這樣的測試，我們必須在編寫這些代碼的時候專門留意如何讓代碼易于測試。從這一點看，可測試性（testability）可以說是最為重要的非功能性需求。

又是差不多10年之后，也就是2021年夏天，Saleem Siddiqui聯系到我，讓我看看他寫的這本書。我忽然想起，明年就是Saleem跟我學習那三門研究生課程的25周年紀念了。他現在是一位成功的技術專家，而且跟Martin Fowler一樣，也成為Thought-works的一員，并且還寫了書。看到這些，我深感欣慰。Saleem讓我給他的書寫序，我覺得很榮幸，而且我急著想要知道他對TDD的看法。

Saleem這本書里最讓我高興的地方是他用一種既直觀又有條理的手法，通過大家所熟悉的日常事例來講解TDD的流程。無論你采用哪種語言編寫程序，“紅-綠-重構”（red-green-refactor）這三個環節[1]，都可以反復執行。作者是拿金融貨幣領域的需求來舉例的，這樣的示例清晰易懂，而且讓讀者能夠逐漸面對更為復雜的挑戰，從而了解如何寫出健壯的代碼，如何在各種細節問題上進行權衡，這樣一來，大家就很愿意更為深入地探索了。在本書最后，作者提出從profile（形象）、purpose（目標）與process（過程）這三個維度（3P原則）來評審代碼，這三方面正好涵蓋了書中所講的各種理念。

本書采用三種流行的編程語言來講解，這三種語言在設計上面可以互相補充，其中，JavaScript與Python已經是業界極為常用的語言了，而Go語言的人氣也在迅速攀升。通過這三門語言，Saleem有力地證明了TDD是一種適用范圍很廣的開發方式。此外，他還多次提醒讀者注意編程語言的設計與剛才說的3P原則之間的關系。

我最希望看到的是許多新一代的軟件開發者在讀完本書之后，能夠堅定地采用測試驅動開發（TDD）這樣一種方式來使用Go、Java與Python等流行語言，這樣能讓TDD傳播得更為廣泛。著名的薩克斯爵士樂手Cannonball Adderley在演奏現場向紐約的觀眾解釋什么是hipness時說過，這不單單是一種想法，而是一種活法（It's not a state of mind, it's a fact of life），我想借用這句話來描述TDD。

Konstantin L?ufer

芝加哥洛約拉大學（Loyola University Chicago）

計算機科學教授

2021年9月于美國伊利諾伊州芝加哥

---

[1] 先根據需求編寫測試代碼，此時由于缺乏能夠滿足需求的正式代碼，所以測試無法通過（紅），然后編寫能夠滿足需求的正式代碼，讓測試得以通過（綠），最后把代碼調整得更加完善（重構）。