Re: [討論] 工作上寫單元測試的比例
※ 引述《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.
--
但這個去狀態化常常是個大工程,要解耦合重構半天欸QQ
通常是只抽出關鍵計算,重要的不是完整的流程,而是會出錯的流程。 真的不幸無法去狀態,stub or mock 一樣可以幫助你簡化狀態。
※ 編輯: TonyQ (42.79.169.118 臺灣), 05/02/2024 12:26:12我沒碰過要解藕大半天才能寫的測試,都是範圍問題。越小的
範圍成本越低。
+1 寫的好
滾動式重構 有需要加功能或是修bug的地方再改成新版本
一起提測
同感 寫測試開發還比較慢,測試應該有誤
推這篇正解
要準備很多才能測試真的讓人很不想測試 嘿
另一方面來說花時間研究這個很能增進寫好code功力
41
首Po想請問一下 大家工作上寫單元測試的情況 1.大部分寫完一個功能, 就馬上完成單元測試 2.先把該做的功能寫完, 再回來統一寫單元測試 3.不怎麼寫單元測試5
你講的三種我都做過,還有第四種:TDD 1. TAD,講白了就是先射箭再畫靶,如果你箭射對了那當然沒問題 但如果你一開始就射錯了還忘記拔出來,就是無效的測試 2. 同樣也是TAD,這個是我們被要求做的,code不是我們寫的、但我 們要幫其他team補測試。我主管也覺得很奇怪、我也覺得很奇怪,3
我覺得命題不是寫/不寫。 真的該問的是,工作上 reviewer 也好、或者是開發流程也好, 有沒有辦法【正常的判斷】 test 是不是寫對的。 XD 起碼是 team 能有一定認同的前提。 其實最後都回到 quality check,不然只是繞圈圈而已。 XD17
我想補一個情境 當到新公司或轉到新單位時 發現沒有在做unit test 此時身經百戰寫過上千次unit test的你 會選擇憑一己之力1
先說我不是故意要回兩篇, 但剛看到 landlord (就 joey chen, 江湖名 91) 在 FB 的回應,我覺得也蠻好的, 他說他最近在忙沒空過來,我問過他之後幫他轉過來。 以下基本上逐字照轉 (source from )2
因為大家的討論都很基於心法 實作上相對很模糊 利用這個機會也跟大家請教實作上的方式 因為最近工作被指派要針對公司產品的程式做整理,其實運作都還好 只是大家功能是一層疊一層,一堆巢狀邏輯,跟依賴中的依賴7
ㄅ是啊,你應該是先有需求才有測試, 通常是先假設已經在線上的已經經過線上考驗。 如果沒有這種需求,你根本就不應該整理。 我個人認為任何在沒有需求的前提下情況下整理程式碼, 是一個浪費自己時間又沒意義的行為。2
原則上要寫測試的話我會用很古老的 TDD 的方式做,先寫測試之後再寫實作。 現在的話則是寫完測試之後 Copilot 就幫我寫完一半了,然後就開始 review copilot 的 code 了。 目前經驗上能不能寫測試的話我認為有三個維度會是主要影響關鍵,提供參考: 1. 文件是否齊全16
分享最近遇到的鬼故事 當初開發完A功能後有順手寫了UT確保該功能基本能動 後來有同事在開發B功能時把他的B功能加進去我的UT default flow內 也沒有請我code review 導致我在跑UT時發現不預期的行為
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來33
Re: [討論] Unit test 的撰寫請益先說結論,先都不要寫。 Legacy system 要先補大範圍的 integration test,確定整體的行為是對的。 如果 code 沒有要再改,不用補細部 unit tests。 原因是因為,原本 API 可能因為設計不良,導致無法寫 unit test 得先 refactor 才有辦法讓它變成 testable,這情況就要先 refactor 再補 UT24
Re: [請益] QA學生實習的問題其實我也有類似的問題,小弟我目前也在某美商當軟體測試實習生 因為公司原本員工眾多,但隨著部分產品開發成熟的關係,有些東西已經轉往美國 很尷尬的是,因為過去人數多,所以整個開發流程根據板上,應該算滿正式的(吧? 專案管理有用 Jira,手動測試後要寫 automation test case,用 robot framework 因為這些自動化程式會放到 Jenkins 上,所以我們也有用到 Git23
Re: [討論] 怎樣算是一個合格的junior cpp programme針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖!重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題,TDD 不只要測試,還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序,是否一定要 TDD 這有爭議 08/23 21:3417
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳16
[討論] Unit test 的撰寫請益先說我對 Unit test 的看法:測試單元(可能是 function)的邏輯是否正確 好,進入正題 小弟最近剛工作,稍微讀了一下負責的 project 的程式碼後, 要開始開發 Unit test。 現況是,各個 file (.c) dependency 很重,13
Re: [討論] Unit test 的撰寫請益先說在前面 雖然聽起來很幹話,但很多東西沒有標準答案 有時是合適度的問題,也可能是喜好(品味?)的問題 同一個題目,實際的 code 長得不一樣,可能也會用不同的方法處理 另外,除了資源豐富到人力充沛到不行的專案,以及幾乎沒有時程壓力8
Re: [請益] 如何當軟體QA??之前寫的軟體測試幾個層級,提供參考。 最入門的狀況,Intern/工讀生通常只會碰到這 A. 依照Test Case進行測試。回報Issue,重現步驟 B. 有能力建置測試環境到可以部屬待測軟體。 測試的軟性觀念,這邊開始才真的進入測試的領域。