TDD：在哪裡開始第一次測試

所以我做了一些單元測試,並且有經驗的寫測試,但我還沒有完全接受TDD作為設計工具.

我目前的專案是重新組建一個生成序列號的現有系統,作為公司組裝過程的一部分.由於檢視現有系統,我對當前的流程和工作流程有一個瞭解.我還有一個新的要求清單,以及如何修改工作流程.

我覺得我準備好開始編寫程式了,我決定強迫自己從頭到尾都是做TDD.

但現在我不知道從哪裡開始. (我也想知道我是否欺騙TDD程序已經有了使用者的程式流的想法.)

使用者流是真正的序列,只是一系列的步驟.例如,第一步是：

>使用者提交製造訂單編號,並收到該訂單材料清單的可序列化部件號

當用戶選擇其中一個部件號時,下一步將開始.

所以我以為可以把這個第一步作為起點.我知道我想要一塊程式碼,它需要一個製造訂單編號,並返回零件編號列表.

// This isn't what I'd want my code to end up looking like
// but it is the simplest statement of what I want
IList<string> partNumbers = GetPartNumbersForMfgOrder(string mfgOrder);

閱讀肯特·貝克的例子,他談到選擇小測試.這似乎是一個很大的黑盒子.它需要一個製造訂單儲存庫,我必須爬行一個產品結構樹,找到這個mfg訂單的所有適用的零件編號,我甚至根本沒有在程式碼中定義我的域模型.

所以一方面看起來像一個糟糕的開始 – 一個非常一般的高階功能.另一方面,我覺得如果我從較低級別開始,我真的只是猜測我可能需要什麼,這似乎是反TDD.

作為附註…這是怎麼使用故事？

作為彙編人員

我想在製造訂單上得到一個零件編號列表

所以我可以選擇哪一個序列化

要真實的是,彙編人員永遠不會這樣說.所有彙編人員都希望在製造訂單上完成操作：

作為彙編人員

我想用序列號標記零件

所以我可以在mfg訂單上完成操作

這是我如何開始.假設你絕對沒有這個應用程式的程式碼.

>定義使用者故事及其帶來的業務價值：“作為使用者,我想提交製造訂單編號和該訂單的部件號列表,以便我可以將列表傳送到庫存系統”

>從UI開始建立一個非常簡單的頁面(讓我們假設它的一個Web應用程式)有三個欄位：標籤,列表和按鈕.那還夠好,不是嗎？使用者可以複製列表併發送到inv系統.

>使用模式來設計你的設計,像MVC.

>為從UI中呼叫的控制器方法定義一個測試.你在這裡測試控制器工作,而不是資料是正確的：Assert.AreSame(3,controller.RetrieveParts(mfgOrder).Count)

>編寫控制器的簡單實現,以確保返回一些東西：return new List<MfgOrder> {new MfgOrder(),new MfgOrder(),new MfgOrder()};例如,您還需要實現MfgOrder的類.

>現在你的UI正在工作！工作不正確,但工作.因此,我們期望控制器從服務或DAO獲取資料.在測試用例中建立一個Mock DAO物件,並新增一個期望方法“partsDao.GetPartsInMfgOrder()”被呼叫.

>使用該方法建立DAO類.從控制器呼叫該方法.你的控制器現在完成了.

>建立單獨的測試來測試DAO,最後確保從DB返回正確的資料.

>繼續迭代,直到你完成所有的操作.過了一會兒,你會習慣的.

這裡的主要目的是將應用程式分成很小的部分,並單獨測試這些小部件.