Re: [討論] 工作上寫單元測試的比例
我想補一個情境
當到新公司或轉到新單位時
發現沒有在做unit test
此時身經百戰寫過上千次unit test的你
會選擇憑一己之力
引入測試框架及補完所有模組的單元測試嗎?
當然這也代表那些高耦合的模組你要想辦法拆分
其中改壞了算你的鍋,改好沒人在乎
而且高機率你得自己維護測試code
還是選擇打不贏就加入?
我很好奇
大家可以分享一下嗎
我自己是選擇不改啦
--
甚麼叫做一己之力? 甚麼叫做自己選擇? 請開會討論
你上面叫你改你就改, 叫你不要改就不用改
你想改本來就要知會主管不是嗎?還是你當的RD沒權力在軟
體品質上提意見?
所以團隊如果不支持就不用改了
如果團隊支持, 那就不是你的鍋, 也不會沒人在乎
這種工作吃力不討好,除非主管說你考績會變好,不然就算了
是不是99%台灣的公司都不在意code quality?
這種層級的問題我都會議上報上去,主管決定要排誰來改
。
沒測試就是直接重寫
重寫的時候順便補 上面的人不支持你重寫的話當然就不
去動
就….預設的後續其實不會發生,想改一定是提出來討論,
討論過了才能動工,那這時怎麼可能都給一個人扛,要馬
趁改版時慢慢補,要馬就是慢慢拆出來補,上司一定得跟
進度,也不可能讓人隨意影響到實際運行的商品
你一個剛來的菜鳥什麼都不知道,怎麼可能做的出所有測試
除非前人有留完整且正確的架構圖給你,我是從未見過啦
還有各種獨門秘方藏在某人電腦裡,通常都是主管
你甚麼都不知道要測啥 怎麼寫
沒test的code會有spec給test用? 水星撈到鯨魚機率高一點
一意孤行反而其他不會改UT的一直問你為什麼code CI跑不
過
他們不會問你,會直接跟上面說因為你的東西阻礙產出
然後你就變成影響公司營收的罪人,KPI完蛋,信用掃地
教科書上那些好棒棒的理想留著自己用就好,現實不是這樣
unit test會牽扯到重構,絕不只是寫unit test而已
獨門秘方藏在電腦裡XDDD
新開發的才會用,時間要用對地方,不要只是為了寫而寫
觀察團隊文化而定吧?!
Unit test 絕對要重構 除非原來的dependcies 早就弄好
當然不要寫啊 淌混水幹嘛?測試也是要維護的 沒人寫 後續
也沒人要維護 那測試很快變拉機
等你離開該單位 你寫的測試又變成別人的麻煩
看上面的老闆會不會加錢,不然弄完被開除怎麼辦
還是多寫幾個坑,讓別人踩比較實在
想接這題問:如何能夠提升高層對於 code quality 的重視
度?
每次碰到前人留下來的屎都很想砸電腦不弄了
去公司外面繞一圈看盡好扣爛扣,提升自己的耐受性然後釋懷
可能發展如下,本來運作好好的系統,因為你補了測
試找出潛在問題,另一個是你改壞了。前者可能沒人
在意,是後者那你麻煩很大。
一是期待別人跟上你的成長,另是產生影響力,也許
結果很像,但意義上完全不同。
正解:就把電腦砸了吧 就換工作 不然就自己創業
高層老闆會重視程式品質 也不用等到你來講喇 哈
41
首Po想請問一下 大家工作上寫單元測試的情況 1.大部分寫完一個功能, 就馬上完成單元測試 2.先把該做的功能寫完, 再回來統一寫單元測試 3.不怎麼寫單元測試5
你講的三種我都做過,還有第四種:TDD 1. TAD,講白了就是先射箭再畫靶,如果你箭射對了那當然沒問題 但如果你一開始就射錯了還忘記拔出來,就是無效的測試 2. 同樣也是TAD,這個是我們被要求做的,code不是我們寫的、但我 們要幫其他team補測試。我主管也覺得很奇怪、我也覺得很奇怪,3
我覺得命題不是寫/不寫。 真的該問的是,工作上 reviewer 也好、或者是開發流程也好, 有沒有辦法【正常的判斷】 test 是不是寫對的。 XD 起碼是 team 能有一定認同的前提。 其實最後都回到 quality check,不然只是繞圈圈而已。 XD6
底下這是比較「野性」」的作法,算是實務專案的經驗: 其實我覺得你到一個完全沒有測試的專案,要分兩個策略: 1. 補重要主線的 integration test 反正哪邊常被報修就補哪邊。 如果一開始補不上去就先做下一點,理論上常被報修的地方會一直出現在下一點, 累積多了就可以變成1了。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 再補 UT21
Re: [討論] 重構跟kpi的考量如果 A, B 都沒有任何 tests,建議不要動他。 幫 C 實做這個功能的時候,把 unit test 寫好寫滿,確保 C 是對的 行有餘力,針對 A, B 的使用情境也加上 test case,確保未來在 A, B 確實能重用 (這點很重要,否則很容易程式長得很像你以為可以重用,實際上根本不能) 就先做到這樣就好,確保 C 的品質,同時你獲得了高品質的 reusable 模組17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳16
[討論] Unit test 的撰寫請益先說我對 Unit test 的看法:測試單元(可能是 function)的邏輯是否正確 好,進入正題 小弟最近剛工作,稍微讀了一下負責的 project 的程式碼後, 要開始開發 Unit test。 現況是,各個 file (.c) dependency 很重,15
Re: [請益] 這種情況要怎麼重構我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言: : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言,重構都是發生在農閒的時候13
Re: [討論] 重構跟kpi的考量感覺這個標題就是個假議題,你說不重構A、B因為Unit test來不及寫,那你新寫的C就不 用unit test了? 然後你又說三個code一模一樣,假設你幫C寫完unit test了,那你不就也把AB搞好了嗎? 再退一萬步來講,AB沒有unit test大家用的那麼爽你還硬要去動也只是吃飽太閒,不如 好好寫你C的unit test,寫完大家就用C就好啦13
Re: [討論] Unit test 的撰寫請益先說在前面 雖然聽起來很幹話,但很多東西沒有標準答案 有時是合適度的問題,也可能是喜好(品味?)的問題 同一個題目,實際的 code 長得不一樣,可能也會用不同的方法處理 另外,除了資源豐富到人力充沛到不行的專案,以及幾乎沒有時程壓力4
Re: [請益] 為什麼功能很容易出現BUG?世界上沒有bug free的系統 只能透過寫unit test和自動化整合測試 來盡可能減少bug unit test和自動化整合測試都需要不少時間撰寫 如果你沒有把這些加進預算內