作者 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
WrongHole:4F 05/02 12:34
KeyFSN: +1 寫的好5F 05/02 12:56
yangs0618: 滾動式重構 有需要加功能或是修bug的地方再改成新版本一起提測6F 05/02 13:06
ck237: 同感 寫測試開發還比較慢,測試應該有誤8F 05/02 19:50
viper9709: 推這篇正解9F 05/02 21:05
k7ji91ab5m: 要準備很多才能測試真的讓人很不想測試 嘿
另一方面來說花時間研究這個很能增進寫好code功力10F 05/02 21:06

--
作者 TonyQ 的最新發文:
點此顯示更多發文記錄