看板 Soft_Job
先說我不是故意要回兩篇, 但剛看到 landlord (就 joey chen, 江湖名 91) 在 FB 的回應,我覺得也蠻好的, 他說他最近在忙沒空過來,我問過他之後幫他轉過來。 以下基本上逐字照轉 (source from https://tinyurl.com/rxyerfyw ) 其實講到底根本原因反而是跟產品程式碼的設計能力有關, 產品程式設計得越好,測試程式越容易寫,越好測。 真正需要在測試中做假模擬(隔離)的部分, 屬於外部(擁有權不在我們手上的部分), 例如外部系統的服務(走通訊協定出去,且不屬於我們可以維護跟上版的服務)、 三方(package/SDK)。而 DB, redis之類的 cache 甚至是不需要特別被隔離開的。 這是由於現代科技的便利,讓我們有機會把越來越接近端到端測試的一類, 比例逐步拉高的可行性比過去容易得多。 另一個重點則是當設計越來越偏向高內聚,simple design, 把 code smell 消除到最後回很自然地提煉出 domain model, 有了 domain model, 最複雜的 domain logic 處理一堆散落資料的邏輯都被內聚到model裡面, 沒有 application 層的依賴,model 的單元測試也很好寫。 結論: 1. 要有能力在 legacy 上重構出可測試性 2. 要有能力做出穩定的端到端測試 3. 要能精煉設計,將散落的資料內聚在一起 來代表 domain 的概念提供 domain 的行為, 因為設計上本來就沒有外層的依賴,model的方法也都精簡短小,甚至鮮少回傳值, 自然 API 易用性跟測試都可以比過去萬惡的三層式架構+內嵌無限層依賴注入 的手風琴架構來得簡單跟好測許多。 現在大部分的依賴(注入)都不是本質上需要的,而是被開發人員硬生生切得支離破碎的。 補充一下 TonyQ 內文最後一點: 「如果都沒被報 bug,你也沒有修改它的需要時,幫它加測試幹嘛?」 這超級重要的,這種情況下加測試往往適得其反, 只會建立偽陽性/陰性的測試結果,勞民傷財還造成干擾。 ※ 引述《TonyQ (得理饒人)》之銘言: : 底下這是比較「野性」」的作法,算是實務專案的經驗: : 其實我覺得你到一個完全沒有測試的專案,要分兩個策略: : 1. 補重要主線的 integration test 反正哪邊常被報修就補哪邊。 : 如果一開始補不上去就先做下一點,理論上常被報修的地方會一直出現在下一點, : 累積多了就可以變成1了。 : 2. 假設自己是維護歷史功能,提昇自己維護部分的可測試性。 : 舉實際案例好了,假設我今天再做一個算金流手續費的專案, : 發現過去算手續費假設有11個地方寫了11次好了,所謂的高耦合不外乎如此。 : 我會先寫個 util 把輸入跟輸出「去狀態化」,然後針對這個 util 寫, : 然後這個 util 的單位以「去狀態化」成本可控,可在手邊開發時間允許的範圍進行。 : 白話文:我橫豎都得手動測試,那就把手動測試的部分, : 盡可能的透過 test code 來進行。 : 如果不想接著維護的話也很單純,任務結束後把 test code comment 掉或移除就行。 : 題外話,11個地方,我會選擇先取代一個地方, : 然後等其他10個地方有需求變更時,一個個整併,補強測試條件。 : 很多人會說,那為什麼不一次改11個,理由是你的開發時間跟成本允不允許。 : 更重要的是你的QA資源夠不夠,因為寫正常的Test最累的是準備測試情境, : 這真的是會花掉比寫test更多的時間。 : 如果列不出完整場景,貿然修改既有的code只是在裸奔。 : 有需求的部分是被迫裸奔,但沒需求的部分不用主動當暴露狂, : 等待驗證過再慢慢統一。 : 大原則就是:你橫豎都是要測試的,只是手測還是寫程式測,除了跟 gui 有關的東西, : 多數的情況下寫程式測試都還是比較省時間的。 : 更棒的地方是,在這種策略下,你往往可以用比同事少30% 的時間完成任務, : 而且因為你的測試成本比較低,所以品質也會比較好,出問題的時候也更容易對焦。 : 然後我通常是會跟同事說我寫了幾個 test case, : 他們願意看就看,不願意看我就放著。不會勉強他們加入。 : 如果你做不到可以用比不寫測試更短的時間來完成任務, : 那你學的測試根本性的就有問題,不寫也罷。XD : 3. 極端情況: 如果都沒被報bug,需求也都很小? : 那你操心他幹嘛 XD -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.163.94.23 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1714628003.A.C91.html
s310143: 當runtime 遇到eos 或是os因資安規範須要升版 05/02 13:46
s310143: 你沒寫測試 會很慘無從下手 尤其你的規模越大 服務越重要 05/02 13:47
s310143: 是不允許 在正式環境 掛掉的.. 05/02 13:49
chchang0820: 我菜雞,覺得好多用詞,有白話文版本嗎? 05/02 13:49
TonyQ: 直接問哪些詞看不懂 比較快 XD 05/02 13:49
Kroner: 吃過關節保健品,都沒什麼效果,有推薦的牌子嗎? 05/03 13:13
Litfal: 但蟲子就是會生在髒的地方,尤其是那一盤盤的陳年義大利 05/02 15:54
Litfal: 麵裡面,被抓去救火就得在時間內細細品嚐 05/02 15:54
superpandal: 依賴注入都不是致命的 致命的是隱藏實作細節 如果是 05/03 01:48
superpandal: 普通使用者當然不用隱藏就很好的屏蔽了 但框架的使用 05/03 01:49
Kroner: 關節痛就老人病 05/03 13:16
superpandal: 者也是開發者 這時候隱藏實作細節絕對帶來的麻煩很大 05/03 01:50
superpandal: 封裝是一定要封裝的 但搞到無法無腦除錯本身就不是很 05/03 01:52
superpandal: 值得一而再再而三提出的優點 花費過多時間在關注無用 05/03 01:53
superpandal: 的小細節也壓根不會學到什麼東西 很多框架都是這樣 05/03 01:55
Chricey: 有人用過中醫針灸治療關節痛的嗎?效果如何? 05/03 01:55
superpandal: 倒是容易被拿來搞人 我是不知道那些人職涯裡心裡陰影 05/03 01:57
superpandal: 有多大 但這樣搞何嘗不是內卷 05/03 01:58
banana13: 超煩的 一堆coverage要衝...升級個idk降到不行重寫頭好 05/03 13:12
banana13: 爆掉出個logger不行嗎 05/03 13:13
Kroner: 吃過關節保健品,都沒什麼效果,有推薦的牌子嗎? 05/03 13:13
banana13: 升級衝majito 套件重寫也沒有比較好QQ 05/03 13:13
banana13: 我覺得可以增加常見utils 做基礎條件測試,當整個程式專 05/03 13:16
banana13: 案被要求覆蓋率 05/03 13:16
banana13: 真的是做給老闆看的了xD” 寫到吐 05/03 13:16
Chricey: 看到關節痛,我就想起我姨媽 05/03 13:16