Re: [討論] 怎樣算是一個合格的junior cpp programme

針對關於 TDD 的討論另外回一篇好了
覺得用推文太長了 XD

補充一下，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

Testing 相關的東西常常是這樣，因為一開始看不到立竿見影的成果，
花掉的資源，也沒有立刻轉成給客戶的價值，跟下水道工程一樣重要但看不見。

這個事情我覺得不是 TDD 的鍋，需求不明確本身就很痛苦，TDD 只是讓你提早面對它
需求不明確或是改來改去，你連 code 該怎麼寫，寫出來該有什麼行為都不知道
自然是無法寫出 test case 的。但反過來說如果狀況是如此，你寫出的 code 會對嗎？
錯是錯在沒定義清楚程式行為，不是 TDD 的錯。
TDD 只是一面鏡子，讓你提早發現問題，事實上這是好事。
表面上測試寫得很艱難拖慢進度，實際上是反映團隊溝通不良，和需求不清的問題
我們應該解決問題，而不是解決發現問題的人(跳過測試不做)
如果放棄做測試來節省時間，做出問題一堆的產品，這些時間後面也是要加倍還...
但也有情況例外，就是做 MVP 的時候。還來不及做測試，產品就被取消了，就免還債 XD

這或許不是 TDD 的鍋，domain 掌握不足，設計出來的 API 多半也會是有問題的，
TDD 並沒有讓事情更糟，只是強迫問題更早浮現罷了。

說了半天整篇都在幫 TDD 護航，但我自己大多是沒在用 TDD (汗顏...)
主要原因還是真的很難習慣，而且經驗比較不足，有時候 API 設計也是 try & error
雖然整個軟體巨觀該有什麼行為已經訂出來了，但程式會拆成很多小模組
每個模組該有哪些行為，完全端看你怎麼拆，而很多時候就是這點難以決定，
需要稍微實驗不同的作法，在這個階段強迫要先寫 test 還真有點強人所難。
但如果是定義很明確的 API，例如 web 後端的 RESTful API，介面都已經訂好了
這時候遵循 TDD 先寫 test case 完全是可行的，有興趣的朋友不妨一試!

--
Sent from PCMan on PCMan's PC

--