[BDD][TDD]BDD in .NET–TDD 在實務上最後一塊拼圖 （投影片分享）
前言
歷時兩天的 WebConf 2013 ，1/12 與 1/13 在中研院圓滿結束，很高興獲得 pct 與 高見龍 的邀請，讓小弟有這榮幸可以上台分享一些實戰的經驗給大家。
這一次的分享主題是: 「BDD in .NET–TDD 在實務上最後一塊拼圖」。
內容主要介紹了 TDD 在實務上導入時，最常見也是卡住最多人的一些問題：
- 測試案例怎麼來
- 怎麼確保程式的執行結果滿足使用者需求
- 怎麼讓團隊中每個角色，以及軟體開發流程中每個階段，中間的溝通與轉換成本降到最低
怎麼透過 BDD 來設計測試案例，貫穿整個軟體開發流程，就是這一次 session 的主軸。
投影片
相關參考
這次的主題範圍，其實大概是前面系列文：[30天快速上手TDD]目錄與附錄 裡面的 Day 23 ~ Day 30，所以想了解全貌或實作細節的朋友，也可以參考一下該系列文的文章。
其他參考：
結論
TDD 要完整或要在實務上導入的比較順利，其實需要許多基礎功的建立，以及其他配套措施的搭配。
基礎功包含了：
- Testing: 單元測試、整合測試、驗收測試的了解與實作。
- OO: 如果是 C# 或 Java 等物件導向語言，那麼物件導向的基礎更是最重要的基底。包含了 OO 三大特性、兩種抽象、SOLID 原則、介面導向、IoC/DI、YAGNI、KISS、DRY 等基本原則。
- Refactoring: 重構使用的相關工具與技巧
- 設計方式: top-down 的設計方式，抽象的能力。
配套措施則包含了：
- CI infrastructure: 如版本控管、建構腳本、CI server 的建立、靜態程式碼分析的工具、報表的呈現、建構品質趨勢或狀態通知、自動佈署等等。
- Scrum: 秉持著 Agile 的精神，透過 Scrum 的軟體開發流程輔助，才能解決 TDD 開發方式所產生的一些角色之間合作，以及軟體開發流程中所會面臨軟性問題，例如需求定義太詳細，導致無法有效率的擁抱變化，導致需求異動時要花的成本過高。又例如需求定義的太簡單， developer 該如何迅速確保自己設計的方式是使用者需求要的。諸如此類的軟性問題，使用 Scrum 進行開發是絕佳的選擇。
- 開發流程的慣性改變: 例如 PO, QE, developer 如何成為一個 team ，在每個階段都共同合作、迅速回饋、擁抱變化。如何先設計測試，再進行開發。如何沒有多餘的文件，又可以進行交接，又可以讓每個角色都能清楚了解使用者需求、系統功能、使用系統與模組的說明書。
這一次的 session ，我有刻意避開太多程式實作的細節，一者當天的聽眾不一定都是 developer ，再者使用 .NET 相關技術的聽眾應該是佔少數。講者並不是主角，重點在於聽眾離開會場時可以帶走多少收穫、激起多少熱情、如何引領他們能主動去了解相關內容，才是講師講課的價值所在。
因此這一次重點是想辦法打通大家在 TDD 實務上想法的關卡，以及給大家一個願景：在實務中，軟體開發也可以是一件多麼美好的事。
blog 與課程更新內容，請前往新站位置：http://tdd.best/
