測試驅動開發Test Driven Development

By 黃升煌

2

參考資源• 在國外不認識 Uncle Bob就等於不會 TDD

網站 : http://butunclebob.com/ArticleS.UncleBob

• 在台灣不認識 91哥就等於不會 TDD 課程 : https://skilltree.my/events/mbh 網站 : https://www.facebook.com/91agile 書單 : https://91-tdd.hackpad.com/91--SCin8rM6vpI

這是一個開發人員小明的故事如有雷同，純屬巧合

4

小明是個剛出社會的程式開發人員…在 XX公司擔任系統開發的工作

5

這是小明習慣的系統開發流程…

需求 撰寫程式 手動測試 交付系統

6

工作幾個月後，小明發現自己的工作遇到了一些問題…

7

小明常常覺得自己開發系統像無頭蒼蠅

8

寫出來的程式碼感覺總是難以維護

9

辛苦開發出來的系統，總是不太符合 user的需求

10

最討厭的是，測試程式好花時間，好不想測

所以乾脆不測或只測一些部分倒楣的是， bug都剛好發生在沒有測到的部分…

11

主管或 user常常質問小明…

你難道都沒自己測過嗎！？

12

小明覺得自己開發系統的工作像這樣…

13

小明不開心

14

不過，小明是有為上進的好青年

所以小明主動開始尋找一些好的測試方法

15

首先，小明找到了

單元測試！ (Unit Test)

16

最小的測試單位與外部資源相依性為零不具商業邏輯測試案例之間的相依性為零一個測試案例只做一件事

小明暸解了什麼是 Unit Test

17

Fast：可快速知道結果Isolated：與外部資源隔離Repeatable：執行 100次 100次結果應該都會一樣Self-Validation：可以直接從測試報表中理解意義或失敗原因Timely： production code與 test code同時存在

小明學到了 Unit Test的特性─ FIRST

18

找出要測試的目標 (SUT、 System Under Test)

1. Arrange

• 初始化 SUT需要的相關參數、模擬物件2. Act

• 實際呼叫 SUT

3. Assert

• 驗證 SUT是否如預期運作

同時，小明也使用 3A Pattern來撰寫測試程式

19

Demo一下…• 一個加法器程式 DEMO

• 為加法器加上 unit test確保程式正確

20

有了 Unit Test之後小明…有了可以快速驗證程式邏輯正確性的工具而且在改了 A邏輯後，可以立刻知道是否影響到其他的邏輯錯誤在想得到的範圍內，加上單元測試，只要測試都是通過的，小明就可以有信心的說「在想得到的狀況內，我的程式沒有問題」

21

但是，小明又發現了新的問題寫完程式碼，卻難以下手撰寫測試案例當需求異動時，測試案例要不要異動？常常忘了 /懶得要寫測試案例驗證程式，所以測試覆蓋率低落，改東壞西的 Bug還是常發生 (雖然比以前少 )

22

還好，小明是有為上進的好青年

所以小明繼續尋找讓測試案例更容易應用在開發上的方法

23

於是，小明找到了

測試驅動開發！(Test Driven Development、 TDD)

24

關於測試驅動開發，小明學到最重要的一堂課是

重點在開發！重點在開發！重點在開發！因為很重要，所以講三次！

25

Test Driven Development特性• 測試先行• 用測試案例代表需求• 撰寫程式來通過測試案例• 不斷重構，以增強系統架構與可維護性

小明學到了 TDD的一些特性

26

小明學到 TDD的開發流程需求

撰寫一個測試案例

執行測試(紅燈)

針對test case撰寫程式

執行測試

測試結果為(綠燈)

重構程式碼

不需要重構程式碼

是

是否需要重構 是否撰寫下一個測試案例

否

27

小明也學到了 TDD的三個重要原則• UncleBob: http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd1.You are not allowed to write any production code unless it is to make a failing unit test

pass. 在有一個錯誤的測試之前不應該撰寫任何 production code

2.You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 當有一個失敗的測試案例 ( 編譯錯誤也是錯誤 )時，不應該撰寫更多的測試案例

3.You are not allowed to write any more production code than is sufficient to pass the one failing unit test. 除了足夠通過測試案例的程式碼以外不應該撰寫更多額外的程式碼

28

開始使用 TDD開發後，小明覺得一次專注在一個測試案例上，更容易專心了有測試保護程式，能更容易重構程式碼，程式碼變得越來越好維護先寫測試案例再開發，測試覆蓋率極高，改東壞西的 bug發生頻率大幅降低！

29

小明覺得很開心

30

直到小明用 TDD 方式開發完成了第一個系統…小明才發現

跟人溝通才是開發系統最大的障礙

31

小明想拿測試案例說明自己開發的現況

但是主管 /user才不想看到程式碼

32

當需求異動時，雖然有測試案例保護不怕改壞程式

但異動時要修改龐大的測試程式實在好辛苦

33

最慘的是，小明用 TDD完成了兩個需求，也通過測試案例

需求如下 :• 為了避免上下樓梯學生跌倒，我要在樓梯加裝扶手

• 測試案例 : 扶手必須是空心金屬管且佈滿邊緣• 為了避免火警，我要在走廊裝設顯眼的滅火器

• 測試案例 : 滅火器必須放置在牆上且外觀是顯眼的紅色

34

結果開發出來是

扶手必須是空心金屬管且佈滿邊緣滅火器必須放置在牆上且外觀是顯眼的紅色

35

User的反應

36

主管的反應

37

小明不開心

38

還記得嗎？小明是有為上進的好青年

所以小明繼續尋找開發時測試案例能和顧客溝通無障礙的方法

39

皇天不負苦心人，小明找到了

行為驅動開發！(Behavior Driven Development、 BDD)

40

• 與專案有關的利益相關者密切合作• 使用同一種語言溝通 (人話 )• 使用可自動執行的範例描述系統行為• 將人話自動轉成測試程式─人話與測試程式自動繫結• 活的文件 (Living Document)─文件即需求&測試案例；且可直接從文件上得到開發進度和測試結果。

BDD如何解決問題？

• 可針對需求撰寫測試程式，但並沒有真的去釐清需求• 測試案例程式碼對 developer來說可以代表需求文件，但對

user來說是天書• 當需求異動時，測試程式難以同步異動

TDD的問題

小明眼中的 BDD解決的 TDD的一些問題

41

• 用人話描述需求─ Gherkin 語法 :Feature: 用一個簡單的故事描述需求Scenario: 系統行為

Given – ArrangeWhen – ActThen – Assert

SampleFeature:

In order to 避免計算錯誤As a 數學白癡I want to 知道兩個數字相加的結果

Scenario: 兩個數字相加Given 在計算機輸入 50And 按下 + 按鈕And 在計算機輸入 70When 按下計算Then 結果應該為 120

在 BDD中，用人話搭配 Gherkin 語法描述需求規格

42

動態、不斷修改和更新的文件 避免逆向工程：從程式邏輯反推業務邏輯是很困難的 (說不定程式邏輯其實還是錯的 )

將文件、業務邏輯、程式邏輯綁在一起當需求異動時可以同時更新可以用來追蹤開發進度其他…

這些需求規格，可以變成活的文件 (Living Document)

43

小明學到 BDD的開發流程

需求

專案關係人共同討論，說人話並由實例、雛形產生需求文件

由文件產生測試程式 TDD開發 產生

活的文件

44

雖然 BDD有許多好處，但是小明也發現…專案關係人常常都很忙，沒時間聚在一起討論要正確描述可實行的需求也是要溝通技巧的需要密切的配合，代表討論需求的成本也高

45

由於 BDD進入成本相對較高，於是小明決定

用 BDD的精神和 TDD的流程進行系統開發

46

當需求出現時，小明釐清需求並用人話描述需求與規格可能的話盡量多與專案關係人確認需求將需求與測試程式自動繫結在一起針對需求產生的測試程式以 TDD的流程進行系統開發

47

使用這樣的流程開發後，小明發現用人話溝通比用程式溝通輕鬆多了需求異動時改文件或改測試程式都更容易當功能開發完成，文件自動更新結果，更容易追蹤進度

48

Demo一下…• 用人話完成需求規格• 需求與測試自動繫結• 測試結果自動更新到文件上• 透過 CI，在每次簽入程式碼時執行測試並更新文件

49

到目前為止，小明的經驗Unit Test: 確保程式跑起來跟想的一樣TDD: 先想清楚系統如何運作再寫程式BDD: 用人話描述需求，將需求與測試繫結， 減少認知差異TDD/BDD的重點是開發！測試只是順便帶著測試的心態學 TDD會覺得層層阻礙帶著開發的心態學 TDD 便能了解其中美妙將問題拆解成小問題，再一個個解決，開發會更順暢

50

小明很開心！

小明還在持續學習中

以後是否會學到新的方法？

那又是另外一個故事了…The End

補充：關於 UI的自動化測試這裡講的不是開發，是測試

55

問題• 這樣的畫面你要怎麼測？

56

問題• 手動測試的問題

N個欄位要手動輸入 每次測試資料不能打錯 一點點小修改就要重新測試一次 需求異動時改程式 10分鐘，但測試要多久？

57

自動化測試 Web測試─ Selenium

FireFox外掛 可錄製操作行為 可轉成 C#測試程式

WinForm測試 UI Automation

官方產品 https://msdn.microsoft.com/en-us/library/dd286726.

aspx White

https://github.com/TestStack/White

自動化測試 自動化執行的測試腳本 做一次，用很多次 腳本跑完可以自動驗證結果是否正確

補充 : 測試框架

59

測試框架• Jasmine: http://jasmine.github.io/2.0/introduction.html• Chutzpah: https://

visualstudiogallery.msdn.microsoft.com/71a4e9bd-f660-448f-bd92-f5a65d39b7f0

• JUnit: http://junit.org/• JBehave: http://jbehave.org/• PHPUnit: https://phpunit.de/index.html• Behat: http://docs.behat.org/en/v2.5/

Q&A