針對關於 TDD 的討論另外回一篇好了
覺得用推文太長了 XD
: 推 stupidlove0: 朝聖！重要的真的是unit test 08/23 18:47
: → HZYSoft: 回樓上 TDD 問題，TDD 不只要測試，還要先寫測試才寫code 08/23 21:33
: → HZYSoft: 很多人無法習慣這種順序，是否一定要 TDD 這有爭議 08/23 21:34
補充一下，TDD 是還沒有開始寫任何的 code 之前，就先針對
程式寫好之後 "預期應該要有的行為" 先寫 test cases
接著，先跑一次測試親眼看著他 fail
因為還沒寫任何 code，所以測試絕對會 fail，
如果沒寫 code 卻 pass 那表示你的 test case 根本沒有測到。
接著才開始寫 code，重複跑測試直到確認 pass 為止，就是完成了。
不同於先寫 code 再測試，TDD 是顛倒，先測試再寫 code，所以才叫 test driven
如果程式被報 bug，也是先寫一個會 fail 的 test case，確認可以重現 bug
接著才開始改 code 修正，直到測試 pass 為止，就表示修好了。
這是一個觀念很特別的流派，他們的主張都是有道理的，就只是比較違反直覺不好實現。
如果你無法先寫出測試，那表示你還沒弄清楚要實作什麼行為，
或是你原先構思的 API 介面難以使用，以至於你寫不出 test case
這是強迫你釐清 spec 以及設計好介面的方法，但實在有點極端，被不少人視為邪教 XD
: 推 TeaEEE: TDD最大的阻力來自你的老闆 08/24 11:40
Testing 相關的東西常常是這樣，因為一開始看不到立竿見影的成果，
花掉的資源，也沒有立刻轉成給客戶的價值，跟下水道工程一樣重要但看不見。
: 推 wulouise: TDD在需求不明確的時候寫會很痛苦，SPEC改testcase全改 08/24 12:43
: → wulouise: 但只有一個test, 還是可以加快開發的iteration, test編 08/24 12:46
: → wulouise: 譯執行時間通 08/24 12:46
: → wulouise: 通常比跑production快很多 08/24 12:46
這個事情我覺得不是 TDD 的鍋，需求不明確本身就很痛苦，TDD 只是讓你提早面對它
需求不明確或是改來改去，你連 code 該怎麼寫，寫出來該有什麼行為都不知道
自然是無法寫出 test case 的。但反過來說如果狀況是如此，你寫出的 code 會對嗎？
錯是錯在沒定義清楚程式行為，不是 TDD 的錯。
TDD 只是一面鏡子，讓你提早發現問題，事實上這是好事。
表面上測試寫得很艱難拖慢進度，實際上是反映團隊溝通不良，和需求不清的問題
我們應該解決問題，而不是解決發現問題的人(跳過測試不做)
如果放棄做測試來節省時間，做出問題一堆的產品，這些時間後面也是要加倍還...
但也有情況例外，就是做 MVP 的時候。還來不及做測試，產品就被取消了，就免還債 XD
: → foreverk: TDD比較可怕的是工程師還沒掌握domain，寫出不合理的te 08/24 14:04
: → foreverk: st case，而且自己不知道 08/24 14:04
這或許不是 TDD 的鍋，domain 掌握不足，設計出來的 API 多半也會是有問題的，
TDD 並沒有讓事情更糟，只是強迫問題更早浮現罷了。
說了半天整篇都在幫 TDD 護航，但我自己大多是沒在用 TDD (汗顏...)
主要原因還是真的很難習慣，而且經驗比較不足，有時候 API 設計也是 try & error
雖然整個軟體巨觀該有什麼行為已經訂出來了，但程式會拆成很多小模組
每個模組該有哪些行為，完全端看你怎麼拆，而很多時候就是這點難以決定，
需要稍微實驗不同的作法，在這個階段強迫要先寫 test 還真有點強人所難。
但如果是定義很明確的 API，例如 web 後端的 RESTful API，介面都已經訂好了
這時候遵循 TDD 先寫 test case 完全是可行的，有興趣的朋友不妨一試!