今天看了不少朋友轉貼了一些關於 TDD 跟 Unit Test 寫得還不錯的文章，讓我想要順便分享一下一些想法。
很多團隊覺得自己需要 TDD 來提昇產品品質，來提昇 code coverage，來避免改 A 壞 B 的情況，但他們絕大部分都還分不清楚「Unit Test」跟「TDD」的差異。
對他們來說，TDD 就是 Unit Test first，先寫測試，再寫產品代碼。
然而 TDD 遠比 Test First 具備更多的效益，以及相關的技能。
拉回來我想說的，如果一個團隊要搞 TDD，通常我都會先看他們是不是已經把 Unit Test 搞到一定的程度了。
Unit Test 實踐到一定程度時，碰到的瓶頸就會需要透過 TDD 來解決，既享受測試的保護、產品操作說明文件的好處，又沒有「針對 legacy code 後補測試的成本問題」，又不會只是「為了測試產品代碼的正確性，而寫單元測試」。
跳過 Unit Test 想要直接搞 TDD，這步子邁大了，容易扯著蛋。
想要搞 Unit Test 也是一樣的，團隊有沒有 build server（CI server），如果沒有，那 Unit Test 也只是自己寫爽的而已，因為其他人根本不會拉下來跑。
想要搞 build server 也是有前置作業的，團隊有沒有對應的 version control system，如果版控的機制與策略不落實，那 CI server 的運作就不 work。
例如有些專案還沒上到 CI 上，有些在 CI 上的專案有寫測試但根本沒 hook run test 的 event。
或是 CI 上測試 failed 了，build failed 了沒人要修。
或是測試時好時壞的，團隊覺得這是一件習以為常的事。
這些都需要比 TDD 更早點發生，這些問題還沒解決，TDD 真的還太遠。
最後一句話，「TDD 不該被定義成團隊的開發規範，而該是 developer 的良好開發習慣。」
TDD 只是個投資報酬比相當高的開發方式，能用些許成本來達成多個目的的手段。
如果大家的 TDD 是一種可能製造浪費的方式，而不是反過來，更快、更小的驗證可行性，產出結果取得回饋做調整，那你的 TDD 很可能用錯地方，或是壓根就誤解 TDD 了。
