[LEARNING] TDD 與持續重構
91 課程心得 (1) — TDD
91 在 2023 年倒數第二堂的公開課：【TDD 與 持續重構】 #202302 結束了。這次分享的內容會是我對 TDD 的體悟，以及我認為誰適合上這堂課。這周結束前還會分享我學到的一個小技巧：IPO 模型。
📑 TDD 與持續重構
- 這堂課適合誰
- TDD
- 測試 + 開發 = TDD ?
- TDD == Test First ?這堂課適合誰？
先來看看 91 的說法：
根據這些條件，我覺得適合上課的人，不一定要熟悉 IDE 、不一定要有快捷鍵（但還是強烈推薦一下 JetBrains 系列），沒有了解 TDD 也無所謂（如果你覺得你都會的話可能要先思考一下為甚麼你覺得你都會了），但至少至少，一定要會寫單元測試，對單元測試有基本的了解和觀念，你才能在這堂課程中，把專注力全部投入在理解 91 的思路和練習中。
另外，就如同 91 在網站裡所說的，純粹抄筆記是真的不適合這堂課；或者說，不適合 91 的任何一堂課，甚至是任何課：講師給的是觀念，把觀念落實在工作中，內化成自己的價值和原則，必須要透過自主練習。
（以上言論都是我自己的理解，和 91 無關）
91：你們覺得 TDD 是甚麼？
我：（右鍵 google 翻譯）測試驅動開發？
91：🤨
這個是真實發生在課堂上的對話，我相信許多人第一次聽到 TDD 也都得到這個答案：Test Driven Development。
你覺得 TDD 是甚麼呢？你覺得這堂 TDD 的課程，在教甚麼呢？
測試驅動開發嘛，上課當然要上測試跟開發啊！
邊閱讀邊實作《Kent Beck的測試驅動開發》第一章的我，差不多也是這樣想的（請 91 原諒我沒閱讀完就去上課——第一章後半部對我來說有點吃力）。可是如果只是單純的測試 + 開發，我為甚麼還要特地上這堂課？兩個分開來學不行嗎？
測試 + 開發 = TDD？
TDD 的本質的確是透過測試 + 開發來進行的，但最難的不是測試撰寫的當下，也不是寫程式碼的那一刻。想想看，是不是有時候 PM 或客戶根本不知道他的期望是甚麼，只是給你一個時間，告訴你做完就對了？是不是有一些產品，擁有 context 的工程師和 PM 都不在了，但客戶需要你幫忙新增功能，你只能看著一坨 💩，手足無措，怕改 A 壞 B？
最難的不是測試撰寫的當下，而是你要怎麼設計你的測試，確保你的測試可以在目前所有想像到的情境下，保護你的程式碼；最難的不是開發，而是開發完之後，你要如何進行後續的維護——賺錢的總是 Legacy Code。
後半段就是本次課程的另外一個議題：重構，前半段則是我這次想先分享的議題：TDD。
TDD == Test First？
回到一開始的問題，你覺得甚麼是 TDD？測試先行嗎？那一般情況下，你的測試是怎麼寫的呢？會給定一個 Input，預期他會有一個 Output，藉此驗證你的程式碼邏輯正確，對吧？
也就是說，一個測試會是一種情境（Scenarios）：當使用者做了甚麼操作，他預期要看到甚麼結果。既然測試等於情境，TDD 等於透過這些的情境，來建立我們對於程式碼的預期，進而達到開發的目的之一：打造符合使用者需求的產品。
情境是使用者的需求，是我們想出來後，和使用者確認後的結果——也就是說，要先 Think，才會有 Test。
這就是這堂課給我的深切體悟之一，如果 91 再問一次 TDD 是甚麼，我會回答他
TDD 毫無疑問，是透過 T 來驅動我們的產品開發。但 T 不應該僅僅是實作過程中的 Test，而是更前面就應該要發生的 Think。
設計測試才是最困難的部分，因此，下一篇會分享的 IPO 模型，可以幫助我們更好的從構想程式碼，走到情境設計的階段。
最後要再強調一次，這是我上完課後的體悟，如果你認同我的想法，請你務必要去聽聽看 91 的【TDD 與 持續重構】課程——我可能會超譯，可能記憶有誤差，不論我的心得是甚麼，都不會比你親自去體驗看看來的更直接準確。
如果你反對我的結論，我覺得你也可以帶著你的想法，和 91、和在場的夥伴們碰撞看看，沒有誰對誰錯，那些碰撞後的產物，也許會讓你有更豐富的收穫。
不論你認同或是反對，都歡迎留下你的想法讓我知道，謝謝閱讀到這邊的你，我們下一篇文章見 👋🏻
