Re: [討論] 工作上寫單元測試的比例
※ 引述《chopinmozart (aha)》之銘言:
: 大家工作上寫單元測試的情況
: 1.大部分寫完一個功能, 就馬上完成單元測試
: 2.先把該做的功能寫完, 再回來統一寫單元測試
: 3.不怎麼寫單元測試
: 想請問大家工作實際情況大概是哪一種QQ
你講的三種我都做過,還有第四種:TDD
1. TAD,講白了就是先射箭再畫靶,如果你箭射對了那當然沒問題
但如果你一開始就射錯了還忘記拔出來,就是無效的測試
2. 同樣也是TAD,這個是我們被要求做的,code不是我們寫的、但我
們要幫其他team補測試。我主管也覺得很奇怪、我也覺得很奇怪,
但反正就當作讀別人程式碼
1跟2的重點其實不是為了驗證,當然你會有機會在寫測試的時候發現
一些錯誤,但主要目標是確保日後別人修改行為一致
3. 純屬玩火,很多公司都在玩火,還玩得爐火純青
但不寫單元測試有時是技術上的困難,有一本書還專門在講這個問
題(書名我忘了,別問、基峰出的我記得),有時也有可能是績效考量
4. TDD,通常是我自己開自己寫的模組才會這樣玩,沒什麼,就是玩兒
台灣經常會搞錯的就是把integration test跟unit test搞錯,很多人其實
是在做前者而不是後者。如果你發現你test failed時你還要找老半天才能
locate the issue,那你很可能是在做前者
但無論哪種,其實沒有test的公司我覺得是最好混的
1. 你commit code不一定要負責任,出事了就說歷史共業,有時業在別人身上
2. 出問題了就算知道問題在哪,可以裝作找不到、混時間進度,慢慢解慢慢修
所以台灣的老闆們,請不要讓你的員工導入test文化,謝謝,不然這樣很難混
--
就害人害己 心態上領錢能混就混..時間久了就跟瑪農一樣
不寫測試 後面要改就是外面再包一層 包到改不了就是重構
重構不了就是推新產品 台灣的玩法
主要是人少又要做不明確需求 有些洞只能先挖好以後再補
那不叫重構 那叫重寫
不用台灣 美國人最喜歡玩新東西重寫 比較潮
推二樓XD
好說好說,懂得都懂
還有一種錯誤觀念就是只看 coverage 沒在管測試內容
公司自己做的logging framework,測試都過不去....
當老闆表明就是反向工程其它家產品然後貼上自己的牌子
反而會注重測試,但是這種都是相容性整合測試
很多工程師就是把重構當作自己的credit.
41
首Po想請問一下 大家工作上寫單元測試的情況 1.大部分寫完一個功能, 就馬上完成單元測試 2.先把該做的功能寫完, 再回來統一寫單元測試 3.不怎麼寫單元測試3
我覺得命題不是寫/不寫。 真的該問的是,工作上 reviewer 也好、或者是開發流程也好, 有沒有辦法【正常的判斷】 test 是不是寫對的。 XD 起碼是 team 能有一定認同的前提。 其實最後都回到 quality check,不然只是繞圈圈而已。 XD17
我想補一個情境 當到新公司或轉到新單位時 發現沒有在做unit test 此時身經百戰寫過上千次unit test的你 會選擇憑一己之力6
底下這是比較「野性」」的作法,算是實務專案的經驗: 其實我覺得你到一個完全沒有測試的專案,要分兩個策略: 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時發現不預期的行為
39
Re: [心得] (轉)軟體開發六年後我改變想法的事情這篇滿有意思的,牽涉的主題很廣,不過有些事情只有一句很難講清楚 針對中間幾點,分享一些我自己的理解 ※ 引述《alihue (wanda wanda)》之銘言: : 看到不錯的文章 翻譯分享一下 : 原文: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 再補 UT23
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
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就好啦4
Re: [請益] 為什麼功能很容易出現BUG?世界上沒有bug free的系統 只能透過寫unit test和自動化整合測試 來盡可能減少bug unit test和自動化整合測試都需要不少時間撰寫 如果你沒有把這些加進預算內