怎麼在團隊裡面開展TDD？

01-26

1. 自身團隊對TDD知識欠缺，大家推薦些學習資料
2. 大家沒有這個意識，寧願單個調試，而不願意寫測試用例
3. 怎麼維護測試用例都能通過

4. 怎麼維護測試數據，而不產生臟數據
等等，大家多多指教。

框架要支持。比如 iOS 開發就很難 TDD 。找好的測試框架，找好的例子。

PM 要求要到位。

測試項目和用例之間要一對一。有 review 檢查。

！所有！測試用例要！每天！跑，計算通過率。（每天跑測試用例即包括了對數據的要求：同一個用例的輸入數據要控制好，讓測試做到可重複。）

測試用例要 review 。用例通過而實際測試不通過一定要追究原因。

成果的傳達也很重要。TDD 一旦轉起來，要收集結果。並且讓開發者看到通過率上的變化。

大多數情況下，開發者會喜歡這種開發方式的。

因為進展是可見的，能增加成就感。

而測試是可重複的，能降低degrade的風險，從而減少焦慮。

最後，使用 TDD 的目的是高效的開發高品質的程序。如果發現 TDD 危及這個目標（沒有完美的開發模式，TDD也有自身的弱點和局限），那麼適當的妥協。

針對第三個問題，你需要CI，保證測試時時刻刻都在跑。並且CI失敗視為Blocker。在這一點上如果不能達成共識，測試驅動就無從談起。

回到第一點和第二點。你必須要先解決大家不願意寫測試用例的問題，才能談TDD。TDD可不是寫測試用例那麼簡單，它強調通過編寫最小的能讓測試通過的代碼的方法，讓設計「浮現」。這聽起來很酷，用起來就很可能很扯了。以App Annie的情況，所有工程師都有非常好的寫單元測試的習慣，但幾乎沒有人支持TDD本身。

我覺得可以不要一上來就玩tdd，先做到能一邊寫需求代碼，一邊寫單元測試。在寫單元測試的過程中，你會發現需求代碼組織結構很差，很難寫單元測試，然後你就會重構你的需求代碼。最後你會發現單元測試寫好了，需求代碼的結構也好了，你就會體驗到ttd的好處。我覺得ttd的核心思想就是讓你的需求代碼去適應你的單元測試，而不是把需求代碼都寫好了，再補單元測試！