[Spring.Net & TDD]撰寫BLL與DAL的步驟(包括Unit Test)
前言
由於目前系統開發使用3-layer architecture (Presentation Layer, Business Logic Layer與Persisent Layer)，搭配Spring.Net來做Interface的Dependency Injection。
(以下以Service來稱呼Business logic layer，以Dao來稱呼Persistent layer，Dao也就是Data Access Object，Library就是指這兩層)
因為這樣子的開發方式，如果不用TDD的開發方式，往往把Library寫完後，再撰寫一部份的Presentation layer的網頁程式，run time的時候才能測試原本的Library有沒有寫錯。一旦有錯，也無法區分，究竟是UI還是Service還是Dao哪一層寫錯。
而寫完程式後才回補Unit Test的程式，其實效用是很低的，而且Later equals never。
TDD的好處，就是讓developer撰寫程式前，先從抽象的角度思考，現在要撰寫的function，究竟是要做什麼。
- 在interface時訂好符合抽象意義的class名稱、function名稱
- 呼叫這個function要做什麼事情，會接到什麼樣的資訊回來，該傳入什麼參數該function才能運作
- 瞭解input/output後，就能期望回傳值是什麼，就可以先撰寫好測試程式
- 當implement的實際class一寫好，馬上就能檢查剛剛寫的程式是對是錯。
- 如果測試不通過，則代表
- implement的class程式有問題
- 測試程式的input/output預期檢查有錯
- 如此一來，可以在第一時間發現錯誤，並縮小可能產生錯誤的範圍，並釐清是抽象觀念問題，還是程式撰寫問題
Spring設定檔的部分，我們也會將「實際AP執行」與「測試」分成兩份，
先寫測試的config，測試過了，才複製過去實際AP執行的config。
也由於整個架構與過程為了高內聚、低耦合，切成3-layer再搭配IoC實作Strategy Pattern，所以class變很多，
且各class中間的聯繫僅有抽象的呼叫，實際實作是run time時，由Spring.Net的factory去new實際實作的物件回傳。
所以這邊整理了一下，以這樣子的開發方式為基礎，該以怎樣的步驟撰寫Library會比較順手。
撰寫Library的步驟
Domain object有兩種方式，一種是具備屬性與行為，也就是有property跟function。
另一種則只擁有property的物件容器，將行為全部交給service來處理。
這邊簡單列一下，我整理的開發步驟，不一定適用於各個案子，我也相信應該有更好的方式。
- (如果Domain Object有interface，則先定義Domain Object interface)
- 新增Domain Object (以Customer與Order兩個Class一對多為例)
- Class: Customer
- Class: Order
- 屬性ByCustomer型別為Customer(如果有interface，則這邊使用ICustomer)
- 新增Dao Interface
- IOrderDao
- 定義相關method
- IOrderDao
- 新增Service Interface
- IOrderService
- 定義相關method
- IOrderService
- 設定Spring.Net DI config檔
- Service transaction management proxy
- Service object
- Dao object
- (如果Domain object有Interface)
- 設定Spring.Net供單元測試的config檔
- 撰寫NUnit for Dao測試程式
- 新增Dao Class
- 實作介面
- OrderDao
- 撰寫method內容
- 撰寫相關RowMapper程式 (for O/R mapping)
- 測試Dao Class
- 撰寫NUnit for Service測試程式
- 新增Service Class
- 實作介面
- OrderService
- 定義屬性，要使用哪一個Dao Interface
- 測試Service Class
- RepositoryFactory類別新增一個public method，供Presentation Layer呼叫Library
結論
Unit Test與TDD的開發方式，向來就是「品質(或風險) 與 成本」的tradeoff，
Unit Test其實並不會多難寫，麻煩的是Test Case有相當多的資料需要建立，以及需求改變時，等於要維護兩份程式。
TDD也不是挺難，只是一種習慣的改變。
最難的，是在專案開發過程中，持之以恆…
但是，在面臨到持之以恆的問題之前，請先跨出單元測試的第一步，
不然永遠只能在嘴巴上測試。
blog 與課程更新內容，請前往新站位置：http://tdd.best/
