測試驅動開發筆記

YuChia Wei 收錄於 Development

2022-02-01 2024-03-03 約 1407 字預計閱讀 3 分鐘

測試驅動開發的流程筆記

測試驅動開發 (Test Driven Development)

1 首先

TDD is not Test First!
- Test First 只是 TDD 的一環
- TDD 整個流程包含需求分析與測試案例設計
不是有寫單元/整合測試就叫做 TDD
- 測試只是 TDD 中的其中一部份
文末的參考資料有提供各式建議書籍與相關課程

2 Test First 的類型

此章節為我流理解法，並非正式的方法介紹，若有任何錯誤的地方還請不吝指教！

2.1 Outside In

各種別稱
- Top Down
- London School
- Mockist Approach

Outside In，由外而內的處理，在開始動工前只會決定想要用什麼方式去完成實作，類別的名稱架構、方法等內容，都是在測試實作時一步一步建立的。這種做法我認為是需求優先的做法。

2.2 Inside Out

各種別稱
- Classic school
- bottom-up

Inside Out，由內而外的處理，在開始動工前會先規劃好所有類別的長相，並由最內側開始往外建立測試與調整實作。這種做法我認為是架構優先的做法。

3 TDD 流程

TDD 在開發時會使用底下的流程進行開發

確認需求與討論預期使用的處理方法確認需求內容，並規劃程式中預計使用的處理方案；有沒有需要套用特定設計模式架構、若有數學運算或資料比對，相關作法為和？
設計測試案例依據需求規劃測試案例，定義每個案例會需要的輸入參數與輸出結果。
排序測試案例評估前面建立的測試案例中，那些測試要建立的項目最抽象；定義功能介面與方法簽章的測試優先，再來就是確認下一個要完成的測試要改動的項目最小。例如：
1. 沒有預算資料_輸入 2021/07/01~2021/07/31_7月預算為 0
  - 定義了輸入 (是一個日期範圍)
  - 定義了輸出 (我要拿到的是一個數字)
  - 定義了資料來源 (預算的 Repository)
2. 有 7月預算為 31_輸入 2021/07/01~2021/07/31_取得31
  - 完成從預算 Repo 取得資料後輸出的功能
3. 有 7月預算為 31_輸入 2021/06/01~2021/06/30_取得0
  - 確認搜尋範圍小於資料範圍時的結果
4. 有 7月預算為 31_輸入 2021/08/01~2021/08/31_取得0
  - 確認搜尋範圍大於資料範圍時的結果
5. …請報名91的TDD課程以解鎖以下內容…
依據前面定義的測試案例順序進行開發每次案例都應經過以下階段，除非該測試案例是為了驗證其他事情而額外增加的案例；因為這種案例通常是預設現行實作應該要已經有哪些行為，如果這個行為成立，通常會不符合下列的第一項「測試紅燈」
1. 寫一個測試，測試紅燈 (Write a Test)
  - 新加入的測試案例應該會是要加入一個新的功能實作，該功能實作並未完成，這時候通常都是紅燈
  - 若測試剛建立好就是綠燈，通常是
    1. 該測試是為了驗證某個已完成功能是正確的
    2. 該測試案例有問題
    3. 目前實作意外可符合此測試
2. 完成實作，測試綠燈 (Make it run)
  - 在最小修改下完成綠燈
  - 可以刻意讓測試綠燈；可以故意寫一個值讓測試綠燈，確認測試案例的設計正確
  - 修正前面為了通過測試而有的邏輯錯誤
3. 開始重構 (make it Right)
  - 整理實作程式碼
  - 處理程式壞味道
  - 重構修改後都應跑一次測試確保重構並未影響功能
4. 重構測試
  - 整理單元測試的實作程式碼
  - 處理程式壞味道
功能完成

4 自己實務上最常碰到的問題

資料來源過於複雜，在撰寫測試的時候非常不好寫因為我自己在實務上主要使用 EF Core 操作資料庫，再搭配 UnitOfWork & Repository<T> 操作每張資料表，當資料表組合較複雜時，會發生測試中需要撰寫非常多的資料設定的狀況。目前還在思考該如何在有複雜的資料組合的情境下順利的完成 TDD 流程。

目錄