先說我不是故意要回兩篇， 但剛看到 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://webptt.com/m.aspx?n=bbs/Soft_Job/M.1714628003.A.C91.html