Re: [討論] 工作上寫單元測試的比例

看板Soft_Job (軟體人)作者TonyQ (得理饒人)時間6月前 (2024/05/02 11:32)推噓6(6推 0噓 5→)

留言11則, 8人參與討論串5/10 (看更多)

※ 引述《ko27tye (好滋好滋)》之銘言： : 我想補一個情境 : 當到新公司或轉到新單位時 : 發現沒有在做unit test : 此時身經百戰寫過上千次unit test的你 : 會選擇憑一己之力 : 引入測試框架及補完所有模組的單元測試嗎？ : 當然這也代表那些高耦合的模組你要想辦法拆分 : 其中改壞了算你的鍋，改好沒人在乎 : 而且高機率你得自己維護測試code : 還是選擇打不贏就加入？ : 我很好奇 : 大家可以分享一下嗎 : 我自己是選擇不改啦底下這是比較「野性」」的作法，算是實務專案的經驗：其實我覺得你到一個完全沒有測試的專案，要分兩個策略: 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 -- I have a dream, it's silly but beautiful. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.163.94.23 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1714620727.A.F6B.html ※ 編輯: TonyQ (1.163.94.23 臺灣), 05/02/2024 11:34:23 ※ 編輯: TonyQ (1.163.94.23 臺灣), 05/02/2024 11:36:03 ※ 編輯: TonyQ (1.163.94.23 臺灣), 05/02/2024 11:36:27

推

Litfal

05/02 12:15, 6月前 , 1^F

05/02 12:15, 1^F

通常是只抽出關鍵計算，重要的不是完整的流程，而是會出錯的流程。真的不幸無法去狀態，stub or mock 一樣可以幫助你簡化狀態。 ※ 編輯: TonyQ (42.79.169.118 臺灣), 05/02/2024 12:26:12