> ## Content Index > Fetch the complete content index at: https://blog.anthea.day/llms.txt > Use this file to discover other available public pages before exploring further. # TDD 與持續重構 (1) ：TDD 是什麼 - URL: https://blog.anthea.day/learning-tdd-e8-88-87-e6-8c-81-e7-ba-8c-e9-87-8d-e6-a7-8b-6ad370b546566a000f267fd1/ - Published: 2023-02-13T10:20:07.000Z - Updated: 2026-11-07T18:57:37.000Z - Author: Anthea / 芫荽 - Tags: #Migrated-1792241843742, #Import 2026-10-17 12:57, Reading, TDD 與持續重構 ![](https://blog.anthea.day/content/images/2026/10/0-mmzrqcruumlue2zz-1.png) 圖片來源：www.odd-e.com 91 在 2023 年倒數第二堂的公開課：[【TDD 與 持續重構】 #202302](https://tdd.best/courses/tdd-continuous-refactoring-202302/?ref=blog.anthea.day) 結束了。這次分享的內容會是我對 TDD 的體悟，以及我認為誰適合上這堂課。這周結束前還會分享我學到的一個小技巧：IPO 模型。 ```bash 📑 TDD 與持續重構 - 這堂課適合誰 - TDD - 測試 + 開發 = TDD ? - TDD == Test First ? ``` --- ### 這堂課適合誰？ 先來看看 91 的說法： ![](https://blog.anthea.day/content/images/2026/10/1-v_aw39volyma7vs60gg9tg.png) 來自 [91 課堂網站](https://tdd.best/courses/tdd-continuous-refactoring-202302/?ref=blog.anthea.day) 的說明 根據這些條件，我覺得適合上課的人，不一定要熟悉 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 與 持續重構】](https://tdd.best/courses/tdd-continuous-refactoring-202302/?ref=blog.anthea.day)課程——**我可能會超譯**，可能記憶有誤差，不論我的心得是甚麼，都不會比你親自去體驗看看來的更直接準確。 如果你反對我的結論，我覺得你也可以帶著你的想法，和 91、和在場的夥伴們碰撞看看，沒有誰對誰錯，那些碰撞後的產物，也許會讓你有更豐富的收穫。 不論你認同或是反對，都歡迎留下你的想法讓我知道，謝謝閱讀到這邊的你，我們下一篇文章見 👋🏻