您的軟體架構夠敏捷嗎？（三）- 使用 TDD 實現最後的設計
圖片取自： https://2.blog.xuite.net/2/8/9/b/11597010/blog_3502284/txt/218534111/5.jpg 前言 在前一篇文章『 您的軟體架構夠敏捷嗎？（二）- 持續演進的軟體架構 』一個持續演進的軟體架構我們其實做到一半而已，而在上一次，我們針對一個 ATM 自動櫃員機 的需求做了初步的分析，注意了，只是個『初步』的設計，這個設計其實還看不出來程式會怎麼寫，但敏捷又不希望我們在初期進行過多的設計，但是這不代表我們完全不設計啊？這一點我在第一篇文章：『 您的軟體架構夠敏捷嗎？ 』有特別禪述，這裡就不再說講。 下面，我們就繼續將這最後一塊拼圖給完成吧～ 測試先行的軟體架構 (1). 單元測試的最小粒度 在這裡，我們使用 TDD (Test Driven Development) 為主要的開發方法，TDD 是先寫測試、爾後再撰寫實際的程式碼，這部分我想會讀到此篇文章的讀者們應該都清楚這個部份了，還不清楚可參考訪間相關的 TDD 測試驅動開發相關說明，本篇就不再詳述。 重點來了，既然是撰寫單元測試 Unit Test、那麼單元測試不就是寫一段程式碼、來去測試一段程式碼嗎？其實這樣說並不完全正確喔！如果你今天是先撰寫產品代碼、爾後才撰寫測試的程式碼（當然這就不是 TDD 了）這樣說或許還算正確，但是 TDD 指的是一種『開發的方法論』，不單只是撰寫一段程式來測試另一段程式那麼簡單， 因為許多的開發者一提到『單元』測試，就認為單元就是指一段程式碼，但其實不是的， 這裡的單元指的是應該是一個『行為』的『單元』，它是一個獨立的、可驗證的行為。它必須對系統產生可觀察的影響，而這就是我們這裡定義的單元測試的最小粒度，當然，同樣為確保測試的獨立性它又不與其他的行為有耦合情況發生。 (2). 要怎麼測試先行？ 很多教你的 TDD 沒有人在講 UML 啊？沒有關係，我這邊慢慢教你怎麼開始？ 要開始撰寫測試先行的程式碼，我們也得要知道這個系統到底要要幹嘛？對吧？根據前面的 Domain Modeling 就是我們這個系統目前的全貌的樣子，當然這個全貌還不清楚，但最少有個基本的方向，而且方向在第一個最小可行性產品的增量是可以被評估出可以做出什麼，對吧？而我們一開始，也沒有花太多的時間，進行這些 UML 的設計，對吧？算一算，我這裡繪製前面那...