RojerChen.2015.06.05

這一次參加 Joey 在 SkillTree 開設第三梯『自動測試與 TDD 實務開發(使用C#)』的課程，實在是太精采、太充實了，上完課後宛如電影如來神掌，吃了半顆五十年功力的大還單一樣！雖然招式還不會太用，但是已經有了基本的知識與內力，剩下就是重新溫習上課的 LAB，將所學的知識運用至實務上！

過去雖然我也曾寫過單元測試、使用過一些輔助軟體來測試，只是終究我沒有在實務上使用，一方面是自己不熟、另外一方面會覺得這樣會花很多時間，所以最後只做整合測試。但是『出來混的，該還的還是要還』，每當需求異動時，整合測試就超花時間的，因為你根本無法確定這樣改就沒有問題。

透過這三天緊湊且精實的課程安排下，真的是打通了女神卡卡的任督二脈，課堂上除了觀念的教導之外，還包含了快二十多個實作練習，讓我親自體驗『測試』所帶來的效益，透過這樣的練習下，很快就知道問題在哪裡。

未來如果想在公司推動，你可能會遇到程式的問題，如果是程式這樣技術上的問題還好解決。如果是公司流程或是同事的問題，要推動可就難了。不過我認為只要秉持著 Improvement Kata 的精神，我們不要想改變太多，一次只改變一件事情，哪件事情大家最痛最想改善，那我們就朝著這個方向努力，應該就可以讓阻力減到最小。

過去我們的測試都是人工測試，現在我們也開始使用自動化的測試工具，先從 UI 著手。我想當你也去上課，經過這一步步的『洗腦』，應該說是課程安排，我想你也會像我一樣『打從心底認同』，使用這樣的方式，進而持續改善現況！

※課程內容

這三天的課程 Unit Test、TDD、BDD 課程的核心主軸：

『你的問題是甚麼？』

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

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

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

那 Unit Test 有甚麼特性呢？

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

※ 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 工具，就可以讓規格與測試案例一目了然，並且可以清楚的看到測試的結果，一次讓你滿足『需求』、『規格』與『測試』這三個願望。

※延伸閱讀

心得分享：My Toastmasters Journey (16)：我從『自動測試與 TDD 實務開發』學到的授課小技巧