關於 TDD 個人一點看法
我覺得 TDD 最大的用處是讓你 "做一下，想一下"，
這件事本身就很有用，相信有不少人有類似經驗，
很快想到一個版本，在幾個循環後陸續想到 3~5 個改版，
其中則有某個版本特別好實作，可以用初版 1/5 以下的時間完成，
複雜度也更低，更乾淨有彈性
另一個很好用的情形是以更小的粒度當成一個 "完成" 的狀態，
一般是做完測好確認功能無誤後再整理程式，
若做的東西較大較複雜則可能要幾天到幾週才會到完成，
那時再整理會較麻煩，也較容易出錯要再多重測幾次，
用 TDD 的話則不必等到整個完成，中途覺得哪裡怪怪的想調一下隨時可以調，
且調完幾秒內可確認沒有改壞，
只要不要太鑽牛角尖浪費太多時間過度設計過早優化的話就好，
然後我覺得不一定要很小很乾淨才能做 TDD，
就算是很大粒度的 E2E api 測試也有不錯的效果，
真的很細小單純的東西個人倒覺得不太需要使用
另外我覺得 TDD 算是很工程師的工具了，
它只關乎你怎麼進行 development 的工作，
就像要用哪個 ide 或用什麼鍵盤差不多的概念，
用得順手，用起來不會影響工作，自己想用就用即可
初期學習研究工具跟嚐試工作流會比較花時間，
上手後大概知道自己用得順手的情況再適時去使用也就只是幾分鐘的事情
另外個人覺得可以不用完全遵守 "先/後" 次序，
中途某個段落先開發 3 分鐘，開發到一個段落再補相關測試，
我覺得並不會真的有什麼差別，最大重點的 "做一下，想一下" 並沒有被破壞，
也仍然在補完測試後可很快驗證程式
然後其實也不用花太多心思在想 test case 上，
可以先有基本的測試就好，不用一開始就想很多 case 很多細節
舉一些近幾個月的實例，
大概二月在做一組服務相關 API，就是先有 API 測試再開始做，
這讓開發驗證流程非常快速，
自動測試 watch 開著，開發中途存檔完看一下旁邊的 console 就知道狀況，
不用切到瀏覽器打 API 再切回來
前兩個月在做一個較複雜的東西，大概像是服務合約的底層核心之類的東西，
因為覺得較大較複雜希望能在開發中有較即時的回饋故使用 TDD，
然後做著做著在中途發現沒注意將兩個相同性值的資料以不同的型態儲存，
想將它們的型態改成一致的
使用 TDD 讓我能很安心的放手去改然後跑測試
上面這過程我有拍影片給公司其他人看，
後來 react-native 的前端工程師也有用，
若能把邏輯跟 view 切開那測試方式基本差不多，
如果混在一起那可能就要借助一些像 jsdom 之類的工具
※ 引述《NDark (溺於黑暗)》之銘言：
: ※ 引述《HZYSoft (PCMan)》之銘言：
: : 補充一下，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
: 推文看到有人問前端.
: 我個人是做客戶端所以很多傳統的測試方法論對介面其實效用很低.
: 上述段落讓我想起以前寫作的經驗.單純分享.
: 我在2018~2020年在阿布達比UB維護手機線上遊戲Growtopia.
: 當時的案子有很多駭客想要破解我們的遊戲的攻擊行為.
: 當時的主程式教給我一個我以前沒這樣試過的技巧.
: (但我必須強調.這整個系統跟時程就是不允許我們重構.
: 所以也不可能有甚麼有序的測試方式.
: 功能($$$)產生的速度就是比測試碼(COST)來得快
: 該專案幾年的程式碼簡單來講就是靠優秀的程式員無止盡的縫補.)
: 不過.當我分享給同僚的時候.他們都給我一種我在講甚麼歪理的眼神.
: 簡單說
: 我們當時遇到很多透過奇妙行為(譬如說破解封包)來try我們遊戲server的行為.
: 因為那些行為不是正規動作.所以我們的QA部門無法用正規手段重現這些步驟.
: (當然終歸到底就是沒有那麼多時間/資源
: 去真的學著逆向重建一個駭客軟體
: /線上的問題就是以天為單位要解掉)
: 所以我們無法知道這些破壞到底起因如何.(來龍去脈/竄改點)
: 我們只能夠知道具體來說發生破壞的時間點.(ex.爆炸點/因為有exception log)
: A) 爆炸點 已知爆炸發生了.程式碼假如這樣:
: {
: Func1();// 我們只知道這函式進去的特定一行發生爆炸(ex. null reference),
: // 而函式發生前server環境就已經被竄改/攻擊為會爆炸的情況
: }
: B) 埋點: 製作一個駭客的模擬入口
: {
: DEBUG_HACKER_ACTION(); // 製作一個入口,
: // 我們猜測並刻意模擬駭客的行為就是會把上述那個會爆
: // 炸的某個記憶體抹掉.
: Func1();
: }
: C) 用後門指令手動觸發埋點 DEBUG_HACKER_ACTION() : OK 現在可以重現駭客的爆炸了.
: (紅燈)
: D) 修復: 在Func1()裡面布下重重安全機制.只要有異常就吐LOG然後封鎖該玩家(強制離
: 開/行動取消/黑名單,etc)
: E) 這步驟最重要.再次用特殊指令手動觸發埋點DEBUG_HACKER_ACTION() : OK server安
: 全了.Log正常吐出. (綠燈)
: F) 把後門指令+埋點mark起來.上線測試.抓有問題的玩家.封號.
: G) 這步也很重要,如果之後又發生類似的問題.再把後門指令搬過去開起來用.快速觸發錯
: 誤.同時也可以確認之前修掉的問題沒有再出現.
: 好像不是甚麼很玄妙的高招.
: 但是面對一些客戶端/前端無法重現
: (譬如說一秒鐘按鈕連打60下這種不可能正常可以達到的行為所觸發)的問題.
: QA又兩手一攤沒辦法重現只好自救的時候,不失為一個方法.