網路上看到的心得好文

『你的問題是甚麼？』

『你要用甚麼方法來解決問題？』

※ Unit Test 確保程式想寫的和你想的一樣

『說明文件往往過時無參考意義、程式出錯了不知道錯在哪裡、需求異動常常改東壞西』，因此你需要 Unit Test，透過單元測試可以讓你快速發現問題之所在，雖然初期會花費時間與成本在撰寫看似毫無意義的程式，但是在系統由開發進入維護後，效益就會慢慢顯現出來。

那 Unit Test 有甚麼特性呢？

• 最小的測試單位
• 外部相依性為零
• 不具備商業邏輯
• 測試案例之間的相依性為零
• 一個測試案例只測試一件情

要達到這些特性，程式碼重構還是必須的，過去在撰寫程式的時候，我們往往讓物件與物件之間十指緊扣、緊緊相依。這時我們就應該使用介面 Interface，斷開物件與物件糾結的鎖鏈。

過去我們在撰寫程式的時候，常常一個函式數十行或長達數百行，讓程式不僅無法閱讀也無法達到可測試性，這時我們就必須要重構，將各別處理的邏輯獨立開來，這樣我們才能夠讓這所謂的『黑箱』慢慢變成『白箱』。

但是對於已經發臭到不行沒人敢維護的程式碼，到底該怎麼樣重構才好呢？我們可以透過黑箱的測試先錄製測試的結果，比方說用 Firefox Plugin Selenium 來錄製測試案例，再來進行程式碼的重構。

當有了這樣的測試案例來輔助，讓你的程式碼即便再『黑』，擦上 SKII 也能夠讓你『白』回來！

※ TDD 確保你先想清楚才動手寫

當你會寫單元測試後，接下來就可以朝著 TDD 的步伐邁進！

所謂的 TDD 就是 Test-Driven Development 測試驅動開發。

這樣的開發方式對我來說算其實是相當的陌生，過去的開發方式我們習慣先以需求為主，然後構思這個需求需要那些功能，再針對這些功能進行開發。在這樣的過程中往往會過度發散所需要的功能，常常會考量東、考量西的做了一堆例外的過濾。

而 TDD 就是以用『測試』來輔助『開發』，我們先寫好 Test Case，才進行功能的開發，讓 Test Case 從紅燈變成綠燈，才繼續撰寫下一個 Test Case。透過這樣的『輔助』，可以讓你更『專注』在 Test Case 的處理，才不會過度發散浪費不必要的時間在無謂的功能上面。

就跟安西教練說的，『左手只是輔助』，是同樣的道理。

※ BDD 確保你想的是使用者要的

即便是導入 TDD 的開發方式了，難免還是會發生與實際需求不合的狀況發生。

過去我們在運作專案的時候，通常都是由 PM 告知需求，由 SA/SD 進行設計，PG 進行程式開發，只不過 SA、SD、PG 並不貼近使用者，對於系統的使用情境並不了解，透過這樣一層又一層的傳話，導致彼此的隔閡增加，最初一個跟客戶需求不相干的東西發生。

客戶明明要的是香蕉，PM 以為客戶要的是芭樂，結果最後的結果就是製作出一個香蕉芭樂！

為了讓客戶、PM、SA/SD、PG 能夠在同個頻率、使用同樣的語言進行溝通，於是我們可以採用 BDD 的開發方式，BDD 也就是 Beheavior Driven Development，也就是行為模式開發，透過描述使用者的實際使用情境來進行系統的開發。

讓簡單的文字描述實際的使用情境，『讓文字可以式規格也可以是程式碼』

過去我們在撰寫規格的時候，規格內容實在過於生硬，不容易閱讀，但是透過 User Story 和 Scenarios 來描述就讓這一切面的簡單許多。

『誰』想要甚麼

想要甚麼『功能』

當有了這功能後可以達到那些『預期效益』

接下來描述實際的使用情境：

情境一：

『初始條件』

在『甚麼時候』觸發

會發生『什麼結果』

而透過 SpecFlow 這樣的 BDD 工具，就可以讓規格與測試案例一目了然，並且可以清楚的看到測試的結果，一次讓你滿足『需求』、『規格』與『測試』這三個願望。

完完全全取用自：http://rojerchen.blogspot.tw/2015/06/tdd.html