TDD 課程整理

在今年五月的三個周六，上了 91 的 TDD 課程。近日回顧一下各個 Lab 的內容。

首先，我們面對的案子有兩種，舊的與新的。新的案子我們可以從TDD/BDD起步。那舊的怎麼辦？怎麼加入自動測試來驗證需求？



Refactoring ASP.NET WebForm

1. 建立 web testing
2. 從測試專案驅動 web testing
3. 重構，加上註解，並透過 ViewModel 讓邏輯與 UI 分離
4. 重構，擷取方法
5. 重構，職責分離
6. 建立單元測試
7. 重構，擷取介面
8. 重構，獨立生成物件職責

用以上的步驟來把沒有測試保護的專案加上測試保護。
可參考 Lab6 的練習題。






以下是學習的流程與練習的部分

Recap

• 單元測試可以幫助我們什麼？
• 什麼是單元測試？
• 單元測試的特性？

Recap 3A

• 什麼是3A原則？
• 要怎麼透過 IDE 快速產生單元測試？

Lab1:
Scenario:幫產品程式碼加上單元測試

Recap–MsTest Feature

• 有哪些 Event Hook ？
• 要怎麼驗證 Exception ？
• 要怎麼驗證集合是否相等？

Lab2-相等vs相同

Scenario:瞭解Assert的用法

Lab2-驗證集合

Scenario:驗證集合是否符合預期

Lab2-驗證例外

Scenario:驗證是否拋出期望的Exception

Recap–單元測試驗證方式

• 為什麼一次只測一件事？
• 單元測試驗證的三種方式？

Recap-Isolated

• 隔離有什麼好處？
• 直接相依有什麼問題？
• 如何解決相依的問題？

Recap–Stub

• Stub 的目的？
• 如何初始化 Stub 物件？
• 如何決定 Stub 物件行為的回傳值？

Lab3-v1

Scenario: 透過IoC相依介面，區分職責

Lab3-v2

Scenario: 動態產生Stub物件

Recap-Mock

• Mock的目的？
• Mock怎麼使用？
• 怎麼初始化 mock 物件？
• 怎麼驗證互動次數與傳入參數？

Lab3-v3

Scenario: 驗證測試目標與外部相依的互動是否正確

Recap–非Public方法的測試方式

• 直接測非 public 方法的問題？
• 怎麼測試 internal？

Lab4

Scenario: 在測試專案中測試宣告成internal的產品程式碼

Recap-Selenium

• Selenium IDE 可直接錄製 Web 動作與重播，並可以加入驗證命令
• 可將 Selenium IDE 腳本匯出成 C#/MsTest ，透過測試專案執行

Lab5 - Selenium IDE

Scenario: 使用Selenium IDE錄製並執行測試腳本

Lab5 - Selenium WebDriver

Scenario: 將Selenium IDE測試腳本匯出成C#測試程式

Recap-FluentAutomation

• 該繼承哪個Class，才能使用FluentAutomation的功能？
• 怎麼驗證在某個input的text？
• 怎麼按下Enter？
• 怎麼驗證某個DOM是否存在？
• Page Object 應該如何設計？

Lab5 - FluentAutomation

Scenario: 用FluentAutomation 更簡單的撰寫Web測試程式

Lab5 - Controller

Scenario: 驗證LoginController商業邏輯是否正確

Lab5番外篇 - Page Objects

Scenario: 用FluentAutomation與PageObjects抽象使用者與網頁的互動行為

Refactoring Recap

• 重構前務必有測試保護
• 小範圍重構的效益，比大範圍重構來得有效
• 一次只做一件事，切勿邊重構邊加需求
• 先有 code 再重構，比一開始設計時套用一堆 design pattern 來得精準
• 單元測試解耦時，避免不必要的中介層，可使用繼承與覆寫手法來達到 isolated

Lab6 - RefactoringWebStie

Lab7 - PartimeSalaryWithTdd

Lab8-Specflow

Scenario: 使用Specflow進行TDD

lab8-CalculatorTestWithSpecflow

lab9-PartimeSalaryWithSpecflow

lab10-CalculateFeeWithSpecflow

lab11-SpecFlowWithEf

lab12-Living Document

Recap

• 先想清楚這個功能的user story
• 這個user story應該要滿足哪一些scenarios
• 從scenario產生step definitions
• 撰寫step中的測試程式，強迫思考 production code 的設計
• 類別名稱
• 建構式
• 方法名稱
• 參數名稱
• 怎麼使用這個物件的行為來達成需求
• 怎麼驗證這個功能是否達成

Recap

• [Scope(Feature=”xxx”)]用法
• ScenarioContext.Current.Get<T>與Set<T>用法
• [BeforeScenario]用法
• 從Scenario下中斷點偵錯
• Scenario移至定義，移到對應的Step
• Step透過Go to Specflow Step Definition  Usages移至符合的 Scenario

Recap

• Scenario相同的 step，只是參數不同，可以使用 Scenario Outline/Examples
• 只需要把scenario上的<column name>對應到 Examples 裡面的欄位名稱即可

Recap

• 使用外部命令，代表可以被自動化執行
• 開發團隊與使用者，請以Repository上的Scenarios為溝通的基礎
• Living Documents
• 需求以Scenario呈現
• Scenario產生Step
• Step中撰寫測試程式
• 測試驅動開發
• 綠燈即代表滿足需求

實務的TDD循環

 使用Cucumber的實務TDD