PTT評價

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

看板Soft_Job標題Re: [討論] 工作上寫單元測試的比例作者
TonyQ
(得理饒人)
時間推噓 6 推:6 噓:0 →:5

※ 引述《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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.163.94.23 (臺灣)
PTT 網址
※ 編輯: 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

Litfal05/02 12:15但這個去狀態化常常是個大工程,要解耦合重構半天欸QQ

通常是只抽出關鍵計算,重要的不是完整的流程,而是會出錯的流程。 真的不幸無法去狀態,stub or mock 一樣可以幫助你簡化狀態。

※ 編輯: TonyQ (42.79.169.118 臺灣), 05/02/2024 12:26:12

TonyQ05/02 12:27我沒碰過要解藕大半天才能寫的測試,都是範圍問題。越小的

TonyQ05/02 12:27範圍成本越低。

WrongHole05/02 12:34

KeyFSN05/02 12:56+1 寫的好

yangs061805/02 13:06滾動式重構 有需要加功能或是修bug的地方再改成新版本

yangs061805/02 13:06一起提測

ck23705/02 19:50同感 寫測試開發還比較慢,測試應該有誤

viper970905/02 21:05推這篇正解

k7ji91ab5m05/02 21:06要準備很多才能測試真的讓人很不想測試 嘿

k7ji91ab5m05/02 21:08另一方面來說花時間研究這個很能增進寫好code功力