如果你在考慮要不要上 91 的針對遺留代碼加入單元測試的藝術，我建議趕快報名。
我上完發現，單元測試的手法/技巧都只是皮毛。真正重要的是單元測試的使用思維、其代價與限制、以及真正能提高產品品質的單元測試是什麼樣子。這些全局宏觀的想法，看書或和同事討論單點的問題是解決不了的。
有時候問題不是像打乒乓球一樣一來一往，而是需要更高的思維才能解決到真正核心問題。上完這門課才知道什麼是降維打擊，以及自己過去的理解有多單薄。
各位可以試著回答以下問題，捫心自問是否有足夠的說服力。我的心得是，上完課後自己對這些問題的回答，已經不是單純條理地回答，而是會很自然的認為/感覺答案本該如此。且我知道如何實際去做到。
- 若專案僅包含一堆 CRUD 操作，這類專案的單元測試該從何下手？
- Stored Procedure 怎麼測試？
- 單元測試後，通常會產出一些可觀測的測試報告，這些測試報告中哪些指標是有價值的? 哪些是可以忽略? 有沒有針對團隊組織的指標?
- 我想詢問關於既有專案添加測試。它可能已經迭代好幾輪的作者，內部的寫作風格各異，也沒有劃分清楚物件間的關係與職責，在這種情況下內部各種物件大量相依，如果不先進行結構性的重構，根本很難為其寫測試代碼，但是這也代表即將伴隨著極大的風險，面臨這樣的情況，會有更兩全其美的辦法嗎？
- 怎麼測試依賴很多的類別，看很多測試是貼著內部邏輯做測試，只要 production code 改動，測試也要跟著改，要維護二套程式碼好麻煩
記錄一下上完課程的心得
【Different】這次上課的內容，與你在實際的工作上，或是與其他課程你覺得最不一樣的地方有哪些？（試列出3~5點)
- 之前認為單元測試是 production code 的輔助，只是驗證結果而已。現在認為單元測試能驅動 production code 做出更好的設計
- 之前認為單元測試越詳盡、案例越多越好。現在知道測試程式碼也需要維護成本，辨認出需要測試的情境很重要
- 與其他課程差異在，91 教我的不只是單元測試本身的技術，而是讓我明白其代價與限制。什麼是低價值的單元測試，甚至不應該做單元測試。能清楚其代價與限制，才不會因為對這項技術的期望過高、效果卻不如預期，導致污名化、放棄單元測試
【Learned】你覺得這門課裡印象最深刻、覺得最 surprise 的東西、覺得最實用的東西是哪些？（試列出3~5點)
- 實例化需求
- 對 legacy code 做單元測試的方法
- 單元測試辨認出壞味道
- 單元測試結合重構的過程
- 只有在新需求或修正 bug 才寫單元測試，之前覺得很正常，沒想太多。但今天突然發覺核心在於：只有新需求或修正 bug 才會有情境。沒有情境，是寫不出有價值的單元測試的
【Changing】再接下來7天內，在沒有其他人的協助、 支持之下，你打算在真實工作上運用上課學會的內容，做些什麼改變？（請列出一點就好，思考一下目標，重點是真的去執行，可能不會順利成功，會碰到挫折、問題，再帶著這些回來群組發問）
- 開發新需求或修正 bug 時撰寫測試案例。並在過程中使用課程內教學的方式，讓既有程式裡針對我需要改動的地方，使其具有可測試性
【感想、感受】可以寫下你上這門課的感受 (feeling)，也可以寫下因為這門課讓你產生了哪些與自己知識/技能體系的連結，也可以輕鬆地寫下你對這門課的感想
很開心自己有來上課。除了學習，也感受到 91 的熱情