BDD（1）：詳盡的文件就是可用的軟體

BDD（1）：詳盡的文件就是可用的軟體

July 15 22:36~23:59

儲存知識的五種媒介。

Teddy並不是TDD（test-driven development）的狂熱愛好者，雖然以往工作中也曾採用TDD開發專案，但整體來講採用TDD所開發的程式不多於5%，絕大部分的設計還是採用傳統的方式：先設計物件、實作程式邏輯、寫測試案例、重構。

最近幾年有一個流行的名詞，叫做BDD（behavior-driven development）、ATDD（Acceptance Test-Driven Development）、或specification by example。今年四月份C. C. Agile邀請Joey來分享「BDD in .NET - TDD 在實務上最後一塊拼圖」，內容非常精彩，獲得熱烈的回響。聽完Joey的分享，又燃起了Teddy對於BDD/TDD的興趣。

先撇開上面一堆名詞不管，Teddy今天想要在「公堂之上大膽假設一下」為什麼BDD/ATDD在很多敏捷開發團隊中會這麼受歡迎的原因。幾年前Teddy還在學校念書的時候，曾經讀過Phillip G. Armour所寫的一篇文章，叫做《The Case for a New Business Model: Is software a product or a medium?》（該文章發表於CACM, pp. 19-22, August. 2000）。這篇文章提到世界上有五種儲存知識的媒介：

• DNA
• Brains
• Hardware
• Books
• Software

當年Teddy看完的感想是：一般的軟體需求都是以文件形式存在，屬於上述第四種知識儲存媒介（book），但是軟體開發的最終產品卻是以第五種知識儲存媒介（software）存在。因為這種「紀錄知識媒介不匹配」的原因，軟體開發人員需要花費很大的功夫來確保這兩種不同儲存媒介所記錄的知識是否同步，也就引發了軟體工程裡面所謂的追朔性（traceability）問題。

幾乎所有專案的時程很趕，而資源卻永遠不足。因此需求改變的時候，大部分的情況開發人員都是直接修改程式，根本沒有多出來的美國時間去更新需求文件，因此需求文件所記載的內容與程式碼實際完成的功能經常有所出入也是很正常的現象。所以，當想要了解系統功能或是企業邏輯的時候，到底要相信文件還是要相信程式碼，便成為許多軟體開發人員心中永遠的痛（鄉民真情告白：其實…兩者都不可信）。

請鄉民們試想一個情境：如果能夠將軟體需以software的形式表達，那麼需求與產品都是以第五種知識儲存媒介（software）來紀錄，是不是就可以減少「阻抗不匹配」的問題？更棒的是，由於軟體具有可執行的這個特性，只要執行以軟體方式記錄的需求文件，便有可能能夠自動驗證需求與軟體系統是否同步。

身為敏捷開發的愛好者，不可忘記這四條敏捷宣言：

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

第二條提到：「Working software over comprehensive documentation（可用的軟體重於詳盡的文件 ）」。如果「詳盡的文件」本身就是「可用的軟體」，那不是很多問題都解決了嗎？也就是說，如果能夠有一種紀錄需求文件方法，這種文件不但客戶看得懂，而且還可以執行，自動驗證需求與程式實作是否一致，那真的是太好了。

Teddy認為，BDD/ATDD受歡迎的主要原因之一，就是可以將需求變成可執行的程式， 也有人稱之為可執行的需求文件，如此一來某種程度解決了「working software 」與「comprehensive documentation」兩者熟輕熟重的問題（這也是某種牛丸的實際應用案例嗎？）。

這幾年支援BDD/ATDD的工具發展得很快，也很成熟。Joey在C. C. Agile的分享中介紹了.Net使用的工具SpecFlow，Teddy最近在研究的Cucumber（一個Ruby開發的工具）與Cucumber-JVM（用Java重新撰寫的Cucumber）、某鄉民介紹的Concordion等（老牌的Fit、Fitness應該也算吧 ）。工具不少，用起來應該都不難，有興趣的鄉民們可以花點時間研究一下。

友藏內心獨白：讓PO與測試人員看到需求文件的執行結果是很棒的一件事情。