Re: [討論] 工作上寫單元測試的比例
分享最近遇到的鬼故事
當初開發完A功能後有順手寫了UT確保該功能基本能動
後來有同事在開發B功能時把他的B功能加進去我的UT default flow內
也沒有請我code review
導致我在跑UT時發現不預期的行為
搞了一陣子才發現是他亂用了我的UT
雖然說AB這兩個功能初始化的部分完全相同
寫兩個UT確實是會有很多重複的地方
但一個功能一個UT應該是正確的觀念吧!?
不知大家有什麼想法，或類似案例分享或怎麼改善XD
--
老婆01 https://i.imgur.com/VBSwkje.jpg 老婆02 https://i.imgur.com/wdMQImg.png
--
你是對的
驚(?)
把同事扁一頓
好
鬼故事在於 他不用找人code review 就可以改東西吧
常有的事XD
UT = “unit” test，請他去查查什麼叫unit
這就是為何在台灣9成公司裡 根本不要UI的原因 不但沒有享
受到UT的好處 一堆腦殘還會給團隊添亂 算惹吧
UT不是寫了就放著沒事耶 UT也是要跟著程式一起維護的
有一份工作有寫過,因為寫UT才發現自己CODE高耦合
才決定去學設計模式,不過後來工作公司都沒寫單元測試的
還好我同事寫完測試都會先註解掉assert 才發pr真不
愧是老鳥
扁你同事+1，在臺灣我們先解決人。
好
推上版控自動test 跑不過不能merge回主要分支
這個補充一下因為是新功能所以還沒加上去pre-test，不然都要先跑過啦
還有公司沒有版控喔
問題是沒有要求code review
無情開扁
這哪有什麼，就同事寫了個bug的意思啊
你是對的
等於同事寫了個bug沒人發現就上線，該怎麼處理就怎麼處理
沒有人能提出線上版本永遠不會出問題的工作方法吧？UT又
不是銀彈
不是bug 只是UT跑完的結果不是我原本預期的
發現是我原文沒說的很清楚XD
比他資深就請他修或跟他pair 修。比他資淺就自己修吧
寫UT讓我很放心改A不會錯到B，也在寫UT時沒有分的很好的程
式再次有機會被重構，降低耦合
會改到一起不是說明做的範圍很接近？平常應該會交流吧
原來現在unit test 已經開始簡稱成UT了 那整合測試呢 IT?
UT只出現在JD過
Uniqlo
我建議寫一個UT的UT，以確保你的UT沒有被改壞
要的功能是 自測
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了。1
先說我不是故意要回兩篇， 但剛看到 landlord (就 joey chen, 江湖名 91) 在 FB 的回應，我覺得也蠻好的， 他說他最近在忙沒空過來，我問過他之後幫他轉過來。 以下基本上逐字照轉 (source from )2
因為大家的討論都很基於心法 實作上相對很模糊 利用這個機會也跟大家請教實作上的方式 因為最近工作被指派要針對公司產品的程式做整理，其實運作都還好 只是大家功能是一層疊一層，一堆巢狀邏輯，跟依賴中的依賴![Re: [討論] 工作上寫單元測試的比例](https://tdd.best/wp-content/uploads/2021/01/play-for-fun-scaled.jpeg "Re: [討論] 工作上寫單元測試的比例")
7
ㄅ是啊，你應該是先有需求才有測試， 通常是先假設已經在線上的已經經過線上考驗。 如果沒有這種需求，你根本就不應該整理。 我個人認為任何在沒有需求的前提下情況下整理程式碼， 是一個浪費自己時間又沒意義的行為。2
原則上要寫測試的話我會用很古老的 TDD 的方式做，先寫測試之後再寫實作。 現在的話則是寫完測試之後 Copilot 就幫我寫完一半了，然後就開始 review copilot 的 code 了。 目前經驗上能不能寫測試的話我認為有三個維度會是主要影響關鍵，提供參考： 1. 文件是否齊全
爆
[情報] 「刷卡回饋隨手查」App既「刷卡回饋隨手查」網站推出後，一直有人問app，所以也考慮是否要作app，但一方面既 有的網站架構雖然差不多了，可是還是一直在微調，另一方面也是沒什麼經費，要也只能自 己開發，而雙平台程式又不同，雖說自己有在接網站開發的案子，但若要學兩套開發語言短 時間內作app出來，我也實在沒辦法。 不過後來看到flutter這套可以開發雙平台程式，而刷卡回饋隨手查app主要只是個介面，資![[情報] 「刷卡回饋隨手查」App](https://is3-ssl.mzstatic.com/image/thumb/Purple112/v4/74/c5/45/74c54532-a344-f7de-9a00-5594177ee6ad/AppIcon-0-0-1x_U007emarketing-0-0-0-7-0-0-sRGB-0-0-0-GLES2_U002c0-512MB-85-220-0-0.png/1200x630wa.png "[情報] 「刷卡回饋隨手查」App")
爆
[心得] 我在科技業遇到的鬼故事之一講一個我在科技業遇到的鬼故事 這件事主要發生在兩個人身上： A:是我同部門的同事，主要開發kernel層以下的功能。 B:是隔壁整合部門的同事，主要是開始kernel層以上的功能。 有一天A開發了某一個功能，B整合完之後發現會導致資料損毀。於是B發了一個bug給A，![[心得] 我在科技業遇到的鬼故事之一](https://i.imgur.com/13sxjYWb.png "[心得] 我在科技業遇到的鬼故事之一")
67
Re: [請益] 接手外包商的code沒交接也沒人可以問我的第一份跟第二份工作都是這個樣子，一開始你會像麻痺的人，給你幾個建議 1. 掌握啟動前的入口 - 大部分程式語言都會有一個從作業系統下命令開始執行 的進入點，可能會載入 config、環境變數、命令參數這些東西，你要先清楚 這些東西的配置意義是什麼。 2. 掌握啟動後的入口 - 如果是 server 或常駐程式，在執行階段就會有監聽行為。56
[閒聊] 我做了一個連載小說、寫系列文章的工具大家好，小弟是工程師 有時候創作文章，會想找工具把多篇整理在一起 順手就開發了一個寫作工具，可以建立故事、新增章節 可以當成是連載小說，也可以當成寫系列文章的工具52
Re: [問題] 遊戲試玩員是不是很爽？小弟進入遊戲業的第一份工作剛好就是遊戲測試工讀生， 當時，很多人聽到我工作是遊戲工讀生時，都會說：好爽喔，玩遊戲還有錢拿， 但實際真的沒有大家想像地那麼開心，讓我來分享一下QA部門的日常。 1. 首先，一般玩家玩到的是已經完成的遊戲，![Re: [問題] 遊戲試玩員是不是很爽？](https://img.youtube.com/vi/g5xVg0iNmWI/mqdefault.jpg "Re: [問題] 遊戲試玩員是不是很爽？")
24
Re: [問題] 為什麼可以有這麼多bug?原文吃掉 小弟不才 只是個廢柴軟體工程師 其實這問題沒有這麼難理解 很多公司在小時候只是隨意做做設計![Re: [問題] 為什麼可以有這麼多bug?](https://i.imgur.com/SNtREeNb.jpg "Re: [問題] 為什麼可以有這麼多bug?")
21
Re: [討論] 重構跟kpi的考量如果 A, B 都沒有任何 tests，建議不要動他。 幫 C 實做這個功能的時候，把 unit test 寫好寫滿，確保 C 是對的 行有餘力，針對 A, B 的使用情境也加上 test case，確保未來在 A, B 確實能重用 (這點很重要，否則很容易程式長得很像你以為可以重用，實際上根本不能) 就先做到這樣就好，確保 C 的品質，同時你獲得了高品質的 reusable 模組18
Re: [新聞] 工會喊加薪7500元 中華電冷處理推文講到TL TL的問題很尷尬 總的來講就是已經形成一個死循環 1.業務單位希望TL端出可以用好用的產品 2.TL每個產品研發人數/時數不夠9
[閒聊] 請問Logi的flow功能我有筆電與桌機,有時候會需要兩邊互傳檔案 發現Logi的flow功能好像蠻符合我的需求 請問如果是傳檔案這個動作,是不是只要滑鼠或鍵盤其中一個有flow功能,就可以做到呢? 看說明好像是複製後,把滑鼠移到另一個裝置,再貼上就OK了. 那這樣鍵盤的flow功能還有什麼特別作用嗎?