Search
寫單元測試請記得，不要自己起 DI framework 的 container 模擬 auto-wired 的依賴注入。
而是自己用 mock framework 產生假物件從依賴注入點注入。
要測一個情境，需要的注入相依物件過多，通常就是職責切分的問題。可能是要做的一件事情太大，可能是依賴的物件切得過細。
https://dotblogs.com.tw/hatelove/2017/01/23/bad-smells-discovered-by-unit-testing
透過橫切面設計（AOP）來達到「正交」式的組合設計，例如 decorator, CoR 責任鍊 等方式的組合，來做關注點跟職責分離。
很多人覺得測試很難寫，通常都是產品程式碼設計有問題，導致測試難寫難維護、難初始化。因為沒見過可以怎麼用更優雅的設計來完成同樣的需求，而總是用 procedure style 在寫流程，自然被搞死了。
最近碰到蠻多朋友或客戶的需求，想要針對 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 產品的架構，發揮地淋漓盡致。
把原本散落在每個方法中一大堆無謂的判斷式（例如一堆 error code 的 mapping 判斷）、pre-condition (例如檢查資料的合法性、是否存在該筆資料）、log的紀錄、performance log 、共同的 exception handling 、cache 的存取、身分檢查，全都從原本又髒又肥的 function 內容中拆解出來。
程式碼複雜度指數下降、測試案例個數指數下降、相依物件個數大幅下降，讓設計恢復成原本「簡單」的模樣，關注點分離，實際的 class 都只處理 critical path, 其他的部分拆解出去，透過 DI, decorator, interceptor 來組合。
連我都沒想到他們可以靠自己拆得這麼乾淨、漂亮、簡單。
也難怪上次上完課之後，回公司推薦完又多了好幾位來報名下一梯次。
有興趣的朋友，下一梯次在九月：
https://dotblogs.com.tw/…/dependency-injection-and-aspect-o…
［註］目前此課程只支援 C#，原因是第二天講解到 AOP 的實作，會有一部分依賴於框架，而我對其他語言的框架還不夠熟悉，還不到可以收費培訓的強度，敬請見諒。
另外，這門課也是大幅度的以重構來進行設計的調整，也會寫到單元測試(使用mock framework)，也會一併帶到相當多的 JetBrains 重構功能，例如 extract method, extract class, extract interface, move method, constructor generator, introduce field, inline field/variable/parameter/method 系列。
