基本介紹
- 中文名：用例驅動開發
- 外文名：(Test-Driven Development
- 重要目的：測試軟體
- 缺點：增加代碼量
簡介,用例驅動開發,創新,UDD vs TDD,系統分析,服務,包庫,客戶應收款,TDD 本質,
簡介
TDD的重要目的不僅僅是測試軟體，測試工作保證代碼質量僅僅是其中一部分，而且是在開發過程中幫助客戶和程式設計師去除模稜兩可的需求。TDD首先考慮使用需求（對象、功能、過程、接口等），主要是編寫測試用例框架對功能的過程和接口進行設計，而測試框架可以持續進行驗證。
缺點：增加代碼量。測試代碼是系統代碼的兩倍或更多。
用例驅動開發
我們做任何事情，背後都有一股驅動力。簡單地說，人類的多數行為都是受到“欲望”驅動。
我們做程式設計師的，也需要一股實實在在的驅動力，來驅動我們完成手頭的工作。如果找不到這股驅動力，或者驅動力不夠強，我們便會覺得心煩；隨便上上網，看看技術文章，學學新技術，不知不覺，一天就過去了。
要高效地編寫代碼，需要高效的驅動力。
用例驅動，是一種高效的驅動力。
創新
TDD 無疑是一種創新方法，或者說是 Kent 獨創的方法（當然，Kent 老是把貢獻歸功於自己的老搭檔 Ward Cunningham），而“創新”方法的問題就在於它的“創新性” —— 除了創造者之外，過去沒有人熟悉它，沒有人想到它，或者說大家過去都不是那么乾的，所以 TDD 才能引起轟動，才能激發大家學習的好奇與熱情。
那么，問題就來了：難道過去的方法都不行了嗎？世界上只有 Kent Beck 一個頂呱呱的、最聰明的程式設計師嗎？答案肯定是否定的。道理其實也是很簡單，過去十年里世界上大概有成百上千個相當成功的項目，可這些項目也沒有用 TDD，Kent 也沒有參加過這些項目呀。
過去十年來，我也一直在編程（從海底、平原到高原，各個層次上的），我本人也親歷過不少成功的項目，有些還是相當 tough 的。我還認識不少國內外一流的程式設計師，他們都遠比我聰明。可在我的印象中，他們好像也不完全是像 Kent 和 TDD 那么做的，也就是說他們擁有不同的成功故事。
一兩個人的最佳實踐與成千上萬人的最佳實踐，含金量明顯不同。所以，搞清楚 TDD 與我們傳統的最佳開發方法（最佳實踐）的真正區別就很有必要了。TDD 到底與我們這些普通人（大眾成功者）過去的做法有何不同？TDD 的真正價值到底在哪裡？它對傳統是顛覆，還是互補？它有沒有缺陷、漏洞？我們怎么用 TDD，讓它發揮最大價值？我想，通過認真、嚴肅的比較和研究，這些問題就能逐一搞清楚。
Kent 在 TDD 這本書中一共用了 17 個章節講述了一個 Money 測試驅動開發的故事。在 2006 年的這個暑假裡，我打算用我所掌握的、熟悉的方法也把這個 Money 案例從頭到尾做一遍。其實上周的某個下午，我已經在 Eclipse 上把結果（答案）做出來了，花了近三個小時。從這次試驗中我獲得了不少有趣的結果，剩下的工作就是如何用可親的文字把我的研究成果告訴大家，與大家分享。
我把我所採用的這個常規方法叫做 UDD（Use Case-Driven Development）。現在外面叫“用例驅動”的方法有很多，所以我只好再加一個前綴，叫 ZX-UDD（暫定名）。我有可能把這個案例分析做成一本電子書（open book with source）。當然，這本書還暴露了我所擁有的，也是天下所有程式設計師所共有的?—— 證明我們不是總是比大師笨，即使諸葛亮也有不敵三個臭皮匠的時候（joking）。
UDD vs TDD
在開始案例討論之前，讓我們先做一下簡短的理論性分析。
既然測試可以驅動開發，那么請問，什麼是驅動測試呢？答案是：軟體需求，具體來說就是反映用戶使用目標的 Use Case（用例）。我們知道，test case 是用例的一個實例（instance），與用例執行的一個情節（scenario，又譯場景）相對應。
系統分析
項目總體概述業務描述
上海普信倉儲有限公司是一家第三方的專業提供低溫倉儲與配送的公司。我們為客戶提供冷鏈食品以及其他需要在低溫下保存的物品的倉儲及配送服務。
服務
（1） 零散倉儲
（2） 包庫倉儲
（3） 倉儲配送
（4） 對外運輸。
不同的服務方式，決定了不同的計費方式。
零散倉儲：是指物品暫存於我公司，客戶不關心具體存放的位置，只需要存放進去就可以了。
然後客戶來我公司通知我公司出庫。這時，對於某個品種，有兩種計費指標，一個是按面積，一個是按噸位。以客戶的某個品種第一次入庫為時間限，然後以一個月為計算單位，一個月內，每平方或者每噸收款。到了指定的日期，就自動生成了應收款憑證。
包庫
相對於零散倉儲，包庫就簡單一些，包庫只需要將指定的庫位包給客戶就可以了，然後按月收費。
倉儲配送：是指我們既為客戶提供倉庫服務，又為客戶提供配送服務。這裡我們往往跟客戶談的是：一年之內，整個交易額的百分比作為倉儲費，百分比作為配送費。但為了核算成本的需要，我們也需要知道這一年內，客戶倉儲的總噸位。
對外運輸：鑒於我公司將購置一定數量的冷藏車，有可能在淡季的時候為客戶提供冷藏運輸服務。
對於零散倉儲和包庫，我們在每次進出庫的時候，還會有一個速凍費（或者預冷費）和上下力資費用產生。
圍繞著以上的核心業務，我們同時會產生以下的數據
客戶應收款
車輛的維護保養費用情況
入庫單，出庫單，配送單，財務結算單等。
除此之外，為了給提供我們的辦事效率，以及減少產品過保質期的損失，因此我們需要對庫位進行科學的安排，以及對保質期進行科學的管理，入庫到指定的位置，出庫到指定的位置去取。
我們的庫位共分為四級，先是1－13的冷庫間，然後是以每個冷庫間的門為左右的庫位，然後，以ABCDEF命名，定位於每冷庫格，每個格從入口處到里，又可以劃分為7列，每列放10個鏟板。
一般我們這樣定義庫位1左A0201表示每個冷庫的左側的A格第2列的01個鏟板。
我們允許庫位的定義在最末一節可以根據客戶的自定義來處理。將01-10這十個鏟板分為前，中，後。也可以分為其他。
TDD 本質
我們知道 XP 中的需求是以“用戶故事”（User Story）的形式描述的，而用戶故事實質上就是一種軟體“特性”（Feature），所謂的“用戶故事”不過是特性的一個別名而已。為什麼 Kent 不把 TDD 叫做 F(eture)DD 呢？大概是因為 FDD（Feature Driven Development）這個名稱已經被別人用去了，FDD 是另一種知名的敏捷方法。當然，Kent 的用戶故事與 FDD 的 Feature 是兩種略有區別的特性。
