Re: [討論] 工作上寫單元測試的比例
先說我不是故意要回兩篇,
但剛看到 landlord (就 joey chen, 江湖名 91) 在 FB 的回應,我覺得也蠻好的,
他說他最近在忙沒空過來,我問過他之後幫他轉過來。
以下基本上逐字照轉
(source from https://tinyurl.com/rxyerfyw )
其實講到底根本原因反而是跟產品程式碼的設計能力有關,
產品程式設計得越好,測試程式越容易寫,越好測。
真正需要在測試中做假模擬(隔離)的部分,
屬於外部(擁有權不在我們手上的部分),
例如外部系統的服務(走通訊協定出去,且不屬於我們可以維護跟上版的服務)、
三方(package/SDK)。而 DB, redis之類的 cache 甚至是不需要特別被隔離開的。
這是由於現代科技的便利,讓我們有機會把越來越接近端到端測試的一類,
比例逐步拉高的可行性比過去容易得多。
另一個重點則是當設計越來越偏向高內聚,simple design,
把 code smell 消除到最後回很自然地提煉出 domain model,
有了 domain model,
最複雜的 domain logic 處理一堆散落資料的邏輯都被內聚到model裡面,
沒有 application 層的依賴,model 的單元測試也很好寫。
結論:
1. 要有能力在 legacy 上重構出可測試性
2. 要有能力做出穩定的端到端測試
3. 要能精煉設計,將散落的資料內聚在一起
來代表 domain 的概念提供 domain 的行為,
因為設計上本來就沒有外層的依賴,model的方法也都精簡短小,甚至鮮少回傳值,
自然 API 易用性跟測試都可以比過去萬惡的三層式架構+內嵌無限層依賴注入
的手風琴架構來得簡單跟好測許多。
現在大部分的依賴(注入)都不是本質上需要的,而是被開發人員硬生生切得支離破碎的。
補充一下 TonyQ 內文最後一點:
「如果都沒被報 bug,你也沒有修改它的需要時,幫它加測試幹嘛?」
這超級重要的,這種情況下加測試往往適得其反,
只會建立偽陽性/陰性的測試結果,勞民傷財還造成干擾。
※ 引述《TonyQ (得理饒人)》之銘言:
: 底下這是比較「野性」」的作法,算是實務專案的經驗:
: 其實我覺得你到一個完全沒有測試的專案,要分兩個策略:
: 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
--
當runtime 遇到eos 或是os因資安規範須要升版
你沒寫測試 會很慘無從下手 尤其你的規模越大 服務越重要
是不允許 在正式環境 掛掉的..
我菜雞,覺得好多用詞,有白話文版本嗎?
直接問哪些詞看不懂 比較快 XD
但蟲子就是會生在髒的地方,尤其是那一盤盤的陳年義大利
麵裡面,被抓去救火就得在時間內細細品嚐
依賴注入都不是致命的 致命的是隱藏實作細節 如果是
普通使用者當然不用隱藏就很好的屏蔽了 但框架的使用
者也是開發者 這時候隱藏實作細節絕對帶來的麻煩很大
封裝是一定要封裝的 但搞到無法無腦除錯本身就不是很
值得一而再再而三提出的優點 花費過多時間在關注無用
的小細節也壓根不會學到什麼東西 很多框架都是這樣
倒是容易被拿來搞人 我是不知道那些人職涯裡心裡陰影
有多大 但這樣搞何嘗不是內卷
超煩的 一堆coverage要衝...升級個idk降到不行重寫頭好
爆掉出個logger不行嗎
升級衝majito 套件重寫也沒有比較好QQ
我覺得可以增加常見utils 做基礎條件測試,當整個程式專
案被要求覆蓋率
真的是做給老闆看的了xD” 寫到吐
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的你 會選擇憑一己之力6
底下這是比較「野性」」的作法,算是實務專案的經驗: 其實我覺得你到一個完全沒有測試的專案,要分兩個策略: 1. 補重要主線的 integration test 反正哪邊常被報修就補哪邊。 如果一開始補不上去就先做下一點,理論上常被報修的地方會一直出現在下一點, 累積多了就可以變成1了。2
因為大家的討論都很基於心法 實作上相對很模糊 利用這個機會也跟大家請教實作上的方式 因為最近工作被指派要針對公司產品的程式做整理,其實運作都還好 只是大家功能是一層疊一層,一堆巢狀邏輯,跟依賴中的依賴7
ㄅ是啊,你應該是先有需求才有測試, 通常是先假設已經在線上的已經經過線上考驗。 如果沒有這種需求,你根本就不應該整理。 我個人認為任何在沒有需求的前提下情況下整理程式碼, 是一個浪費自己時間又沒意義的行為。2
原則上要寫測試的話我會用很古老的 TDD 的方式做,先寫測試之後再寫實作。 現在的話則是寫完測試之後 Copilot 就幫我寫完一半了,然後就開始 review copilot 的 code 了。 目前經驗上能不能寫測試的話我認為有三個維度會是主要影響關鍵,提供參考: 1. 文件是否齊全16
分享最近遇到的鬼故事 當初開發完A功能後有順手寫了UT確保該功能基本能動 後來有同事在開發B功能時把他的B功能加進去我的UT default flow內 也沒有請我code review 導致我在跑UT時發現不預期的行為
26
Re: [請益] 如何當軟體QA??拋磚引玉,台灣軟體測試真的很需要有大大來分享 --- 寫在最前面: 我測試是學這本書 我入門是買中文版,這裡貼的是原文,可以免費線上看,23
[請益] coding style差太多怎辦?大家好 小弟上上份工作快離職前 聽到新進的同事說 他都習慣把程式寫成一個一個小的function 後來離職我花了一點時間學習設計模式23
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:3421
[爆卦] DeepMind的AlphaCode AI也會寫程式AlphaCode achieved an estimated rank within the top 54% of participants in progr amming competitions by solving new problems that require a combination of critic al thinking, logic, algorithms, coding, and natural language understanding. With the permission of Codeforces, we evaluated AlphaCode by simulating particip ation in 10 recent contests. The impressive work of the competitive programming18
Re: [新聞] 輝達A100、H100獨家供應商!法人調高緯創前陣子自家公司GPU也不夠用了...在測試一堆想法時候 決定自掏腰包去租外面GPU 找了幾間像是 結果...wtf 也是大爆滿 看了幾個AI論壇 一堆自行開發者都自己測試各種pretrained model的下游fine-tune 也是各種哀嚎搶GPU 以前這幫個人開發者在自己的RTX 就可以簡單測試 但現在的 LLaMA也好 Diffusion也好 越來越難在家用遊戲顯卡上跑13
Re: [討論] Unit test 的撰寫請益先說在前面 雖然聽起來很幹話,但很多東西沒有標準答案 有時是合適度的問題,也可能是喜好(品味?)的問題 同一個題目,實際的 code 長得不一樣,可能也會用不同的方法處理 另外,除了資源豐富到人力充沛到不行的專案,以及幾乎沒有時程壓力9
[分享] 用一個簡單的數學公式來幫忙設計OOP類別大家好,小弟一直覺得 OOP 很困難、設計類別很困難。 我一直想找一個比較量化分析的方式,在工作時輔助設計類別。 於是我設計了一個簡單的數學公式 跟大家分享一下這個公式,謝謝大家 網頁好讀版:11
Re: [請益] QA學生實習的問題原文述刪 前陣子參加某金控的分享會後覺得有點空虛 加上最近在做內部教育訓練,整理了以前做的一些在自動化測試上的事 少少的經驗 分享給版上QA大大們 希望多多交流7
[心得] ChatGPT協助軟體開發的指令集近來寫程式時大量試用ChatGPT 剛好使用golang開發side project, 所以在各種情況下遇到的問題,都試著問ChatGPT 真的覺得超好用的! 網頁好讀版:附上心智圖、完整範例(有些範例太長,PPT沒有辦法完整呈現)1
Re: [請益] 請教 nand flash 驗證測試職缺1. Storage domain knowledge: SSD、eMMC、Flash(看公司產品) feature大致流程(e.g. WearLeveling 、PLP 、 GC) 2. Testing domain knowledge: Whitebox/Blockbox test 、 Unit test