作者 TonyQ (得理饒人)標題 Re: [討論] 工作上寫單元測試的比例時間 Thu May 2 11:32:05 2024
※ 引述《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 (臺灣)
※ 作者: TonyQ 2024-05-02 11:32:05
※ 文章代碼(AID): #1cCmatzh (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1714620727.A.F6B.html
※ 同主題文章:
Re: [討論] 工作上寫單元測試的比例
05-02 11:32 TonyQ
※ 編輯: 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: 但這個去狀態化常常是個大工程,要解耦合重構半天欸QQ1F 05/02 12:15
通常是只抽出關鍵計算,重要的不是完整的流程,而是會出錯的流程。
真的不幸無法去狀態,stub or mock 一樣可以幫助你簡化狀態。
※ 編輯: TonyQ (42.79.169.118 臺灣), 05/02/2024 12:26:12
→ TonyQ: 我沒碰過要解藕大半天才能寫的測試,都是範圍問題。越小的範圍成本越低。2F 05/02 12:27
推 KeyFSN: +1 寫的好5F 05/02 12:56
推 yangs0618: 滾動式重構 有需要加功能或是修bug的地方再改成新版本一起提測6F 05/02 13:06
推 ck237: 同感 寫測試開發還比較慢,測試應該有誤8F 05/02 19:50
推 k7ji91ab5m: 要準備很多才能測試真的讓人很不想測試 嘿
另一方面來說花時間研究這個很能增進寫好code功力10F 05/02 21:06
--