最近碰到蠻多朋友或客戶的需求，想要針對 ActionFilter, Decorator, DI 的 service locator，middleware/interceptor 或是其他 static helper 相依的情況寫單元測試，卻總是不順、卡手。（尤其是 service locator)
總把測試寫得牛鬼蛇神的，即使看到了綠燈，這測試活超過一個月之後，就人見人厭、爹不親娘不愛的。
更甚至總覺得寫測試很花時間，維護起來更花時間。
其實這些有一半是產品設計不良，有一半是測試設計不良。
（說難聽點，就不是測試的問題，是工程師能力的問題）
很多時候，沒見過人家可以怎麼行雲流水地在 legacy code 上整理、抽絲剝繭，一路用工具重構到具備可測試性，再把測試重構到跟人話、規格、需求情境一樣，是很難想像 #原來可以這樣寫Code 的。
今年的梯次已滿，明天一月的 【#針對遺留代碼加入單元測試的藝術】，只剩下 5 席，live demo 支援 java/kotlin, python, php 與 C#。
參考：https://dotblogs.com.tw/hatelove/2020/08/21/Unit-testing-effectively-with-legacy-code-202101
會不會到時已經可以支援 node.js 與 Ruby 我也不知道，但基本上一法通、萬法通，概念都一樣。
#動態語言其實相對單元測試好寫很多，不寫真的是太浪費了。（寫得醜，更浪費人生）
想要觀望晚點才報名的同學，恩....good luck....luck 可能也沒有用，你的問題可能不在寫程式，而是在執行力上。
動態語言其實相對單元測試好寫很多 在 單元測試的藝術閱讀交流| 面對legacy 產品，在時間資源有限的情況下 ... 的推薦與評價
在《單元測試的藝術》第十章的[表10-1] 依據組件類型來舉例，針對邏輯複雜度、依賴數量、在專案中的優先 ... 動態語言其實相對單元測試好寫很多，不寫真的是太浪費了。 ... <看更多>