用例驅動開發
我們做任何事情，背後都有一股驅動力。簡單地說，人類的多數行為都是受到“欲望”驅動。
我們做程式設計師的，也需要一股實實在在的驅動力，來驅動我們完成手頭的工作。如果找不到這股驅動力，或者驅動力不夠強，我們便會覺得心煩；隨便上上網，看看技術文章，學學新技術，不知不覺，一天就過去了。
要高效地編寫代碼，需要高效的驅動力。
用例驅動，是一種高效的驅動力。
UI--〉控制-->邏輯-->資料庫
我們可以設計這樣一個一般的時間序列圖；
我們進入到邏輯層
有可能需要修改數據結構
我們修改了數據結構，由此可能造成整個UC線的地震
我們不斷在UC線上移動
測試驅動開發 TDD（Test-Driven Development）
測試驅動開發 TDD（Test-Driven Development）是時下一種非常“酷”、非常“靚”的軟體開發方法，TDD 也是一個相當“時髦”的詞（話語），它因 Kent Beck 大師的倡導而全球聞名，成為眾多敏捷方法、敏捷實踐中的一種重要方法。2003 年 Kent 發表了專著 Test-Driven Development (by example)。
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－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 是兩種略有區別的特性。
