作者
標題 [請益] 單元測試用這樣的方式進行合理嗎?
時間 Thu Aug 28 19:43:28 2025
標題 [請益] 單元測試用這樣的方式進行合理嗎?
時間 Thu Aug 28 19:43:28 2025
最近被分配到要去做單元測試Unit test，然後我開始研究某V公司的測試工具，討論編譯
設定、trace32等模擬器如何運行。
然後大概過一個禮拜，研究有點卡頓，因為我第一次用單元測試，而且我不是負責那個專
案的程式專寫。所以遇到一些link error有在詢問V公司解決。
這時負責這個專案的程式擔當來看我怎麼弄那麼久，然後跟我說，這個不需要設定什麼編
譯。
????!!!!我的認知單元測試不是就是動態測試的一種，怎麼可能不用做編譯的設定。
繼續詢問下他說不會直接跑在target上測，也不用到模擬器trace32，直接用一般的g++編
譯器在電腦上跑就可以了，我們只是要"測邏輯"而已。
我有點半信半疑，覺得這個方式怪怪的，我看到的單元測試就是需要模擬實機，所以會需
要用到類似trace32這種模擬器，V公司的人也是跟我們說用這個。
然後更不可思議的是，他直接拿出一包程式，不是原本的專案程式，是經過他"整理過"的
專案程式，替除掉QT、freeRTOS...等等，剩下的程式型態類似於pseudocode的形式，他
說這樣比較好編得過，然後可以測試程式邏輯。
專案程式，替除掉QT、freeRTOS...等等，剩下的程式型態類似於pseudocode的形式，他
說這樣比較好編得過，然後可以測試程式邏輯。
????!!!!是這樣子?這跟已經跟我認知的單元測試不同，這跟測試的概念也相違背了吧。
測試的目的是要"拿真的東西，去模擬的環境測試"，拿人為修過的程式下去測的意義是?
我現在看到單元測試的幾個點
測試的目的是要"拿真的東西，去模擬的環境測試"，拿人為修過的程式下去測的意義是?
我現在看到單元測試的幾個點
1.屬於動態測試的一種，嵌入式系統可使用模擬器進行測試
2.改完程式當下可以馬上看到設定好的測試結果
3.好的單元測試可以能夠完全自動化
即使我是第一次接觸單元測試，我怎麼看他叫我做的方法都不可能是正確的單元測試，然
後用手動整理過的程式下去測試是哪招?
我有提出質疑，他們可能覺得，客戶就是要看報告，如果要做比較正確的單元測試之後在
其他比較簡單的機種上面執行。
我真的不知道該說什麼，因為我沒有很資深，在這方面也不是了解很多，看看各位的想法
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 115.43.108.100 (臺灣)
※ 作者: alan8656 2025-08-28 19:43:28
※ 文章代碼(AID): #1ei43YtS (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1756381410.A.DDC.html
→ : 可以不用糾結於名稱是什麼，問清楚目標就好
但是個人經驗在PC邏輯對不代表在板子上跑的就沒問題1F 08/28 19:51
但是個人經驗在PC邏輯對不代表在板子上跑的就沒問題1F 08/28 19:51
→ : 現階段的目的應該就真的只是要交一個報告給客戶看，這個單元測試是客戶要求我們做才開始做的，這是本公司第一個開始做單元測試的專案3F 08/28 19:57
推 : 我們單元測試指的是google gtest，專門測函數的6F 08/28 20:00
推 : 不要懷疑 單元測試就是只測邏輯7F 08/28 20:02
推 : unit test不用管硬體，只是測邏輯，你想測的單元是什麼8F 08/28 20:44
推 : 你的業主想要你們交Unit Test 報告確定邏輯沒問題就好，而你想要免費送到Integration/ System Test之上我是沒什麼意見 啊你還有時間在那裡摸ㄇ9F 08/28 20:51
推 : 想辦法讓覆蓋率高一點就好啦 至少能交差12F 08/28 20:53
噓 : 你對單元測試的認知是錯的，但他的做法也不算正確。單元測試要能切除所有的相依性，但事先沒有想過這件事，等成品都已經寫成一拖義大利麵之後才開始弄單元測試，是非常困難的！所以他的做法算是不得已的折衷辦法。13F 08/28 21:06
噓 : 第一次用可不可以就閉嘴聽負責人就好？ 是他負責又不是你負責18F 08/28 21:33
→ : 你認知是錯的，UT 只需要管 input output , 所以你餵進去的是假資料也無所謂。20F 08/28 22:51
→ : 假資料我覺得沒問題，但是我比較有疑慮的是他把要測試的程式修改後才去測這件事情。就像模擬考，考試是假的，可是人要是真的，這是我的想法22F 08/28 22:58
→ : 我覺得他講的比較對，你講的還考慮 RTOS 有點接近整合測試
然後就我的經驗，基本上UT就是邏輯通就好，有可能用什麼套件你板子上沒有的，那就是整合的事情
這邊 V公司不是寫程式給你的，他是提供測試軟體的廠商吧？你程式自己公司寫的自己公司要負責啊，為什麼會想問 V公司？25F 08/28 23:13
然後就我的經驗，基本上UT就是邏輯通就好，有可能用什麼套件你板子上沒有的，那就是整合的事情
這邊 V公司不是寫程式給你的，他是提供測試軟體的廠商吧？你程式自己公司寫的自己公司要負責啊，為什麼會想問 V公司？25F 08/28 23:13
→ : 當初不確定問題是出在程式還是工具上32F 08/28 23:28
推 : 單元測試就是要測邏輯 你還牽扯環境不就是整合測試？程式修改也不是不行 弄個編譯選項條件編譯就好 盡量貼近不是一定要一百趴貼近 現實沒那麼完美的
他這做法當然也不太對 他如果有辦法把邏輯抽出來變成獨立一包 理應把這包變成函式庫讓主程式用才對33F 08/28 23:28
他這做法當然也不太對 他如果有辦法把邏輯抽出來變成獨立一包 理應把這包變成函式庫讓主程式用才對33F 08/28 23:28
→ : 感謝大家的指點，這樣看起來unit test要做的好，程式設計一開始就要想到每個函式的獨立運作性38F 08/28 23:44
推 : 你們兩個都有錯 你說的是整合測試
我要更正一下 你同事有可能是對的
如果他是把邏輯抽出來 mock掉不需要測的部分 而且他沒有亂寫測試 那你同事就是對的
完美的做法是包成函式庫。礙於現實考量，我認為把程式碼複製出來另一個專案，做好mock測過沒問題這個做法可以接受，只是你以後要經常維護兩邊的東西一致會很辛苦也很容易出問題
然後你真的沒必要這樣埋頭幹半天才發現根本弄錯方向，你應該像AI一樣做事，你在第一時間就該釐清你打算做什麼，條列出來，拿著你的工作計畫去找負責人確認：「我打算這樣這樣做，你看有沒有問題，沒有問題我就照這樣執行，有遇到問題再討論。」埋頭苦幹最後根本做錯方向就是為什麼資深員工寧願把東西丟給AI做也不想帶新人的原因。你過去一週的表現就像一個收到請求之後要耗費長達一週才回應而且還完全搞錯方向的AI。建議不要再繼續用這種埋頭自幹的方式做事40F 08/28 23:45
我要更正一下 你同事有可能是對的
如果他是把邏輯抽出來 mock掉不需要測的部分 而且他沒有亂寫測試 那你同事就是對的
完美的做法是包成函式庫。礙於現實考量，我認為把程式碼複製出來另一個專案，做好mock測過沒問題這個做法可以接受，只是你以後要經常維護兩邊的東西一致會很辛苦也很容易出問題
然後你真的沒必要這樣埋頭幹半天才發現根本弄錯方向，你應該像AI一樣做事，你在第一時間就該釐清你打算做什麼，條列出來，拿著你的工作計畫去找負責人確認：「我打算這樣這樣做，你看有沒有問題，沒有問題我就照這樣執行，有遇到問題再討論。」埋頭苦幹最後根本做錯方向就是為什麼資深員工寧願把東西丟給AI做也不想帶新人的原因。你過去一週的表現就像一個收到請求之後要耗費長達一週才回應而且還完全搞錯方向的AI。建議不要再繼續用這種埋頭自幹的方式做事40F 08/28 23:45
→ : 了解，我可能也要再去搞清楚整合測試以及單元測試的差別。不要埋頭苦幹要先釐清問題這個道理我知道，但是什麼都不懂就馬上問人也是問不出東西，我通常是先做一點有遇到問題再問，我也還在抓這之間的平衡點。57F 08/29 00:06
→ : 關於如何拿捏問問題的時機，我想補充說明清楚一點，你需要做的是回報你的狀態，回報狀態不是發問，不要求對方花時間給你解答，只是讓他掌握你的動向，不用擔心造成對方反感。你可以至少兩天一次主動寄信告訴前輩你正在做什麼，或者預計要怎麼做，他就會發現你卡在錯誤的方向。我同事每天甚至一天兩次回報狀態我覺得完全沒問題。這不是要你去問對方「我該怎麼做」而是告知對方「我的計畫是這樣」所以你不用擔心這樣的訊息會打擾對方，沒有大問題對方通常瞄一眼就關掉了，方向很歪的話就會跟你溝通。通常帶你的人不想讓自己顯得像控制狂天天盯你在做什麼，你不主動回報就會演變成你辛苦白忙一週還被認定能力有問題。以你的例子你可能在第一天告訴前輩：「我正在處理oo的單元測試，需要花一些時間研究trace32的參數。」第二天告訴他：「早安，關於oo的單元測試，由於編譯有問題，我正在聯絡廠商。」如果這是對的路徑他兩秒就關掉你的郵件了，不會造成負擔。記得每一封信要簡短清楚寫明你正在做的是哪個模組，對方可沒那個腦容量記得每個人是負責什麼部份。就算你對一個工作項目一頭霧水至少你也寫得出「早安，進度回報，我今天要研究哪一塊程式碼」或是「我正在聯絡誰」。只要你別直球叫對方告訴你答案，讓他可以無壓力的已讀不回，就不會踩到對方的雷。61F 08/29 00:47
推 : 真正的問題是叫你做unit test 但你沒做過就直接下去做早期要導unit test 主管還特地開課教學讓大家有共識
畢竟這種方法論還是有很多流派 所以大家有共識很重要82F 08/29 00:52
畢竟這種方法論還是有很多流派 所以大家有共識很重要82F 08/29 00:52
→ : 單元測試也要教喔...經典書籍就 unit testing principles practices and patterns，自己看85F 08/29 01:00
推 : 你扯到系統測試了87F 08/29 01:30
推 : brucetu講得不錯88F 08/29 01:39
→ : 不過呢 我覺得啦 等你認真研究UT一陣子之後呢 就會跟上面報 我們這葛專案不要搞UT好不好 下一個新專案在搞吧 XD
為什麼要UT？其中一個最重要的理由就是強迫你解耦程式
強迫你在寫程式時把邏輯部份抽離 因為這樣才能測試
然後抽離時就會發現 整個系統架構就要大改 然後就.......89F 08/29 01:44
為什麼要UT？其中一個最重要的理由就是強迫你解耦程式
強迫你在寫程式時把邏輯部份抽離 因為這樣才能測試
然後抽離時就會發現 整個系統架構就要大改 然後就.......89F 08/29 01:44
推 : mock data在單元測試很常見喔，看結果應該是你誤會94F 08/29 01:52
→ : 而且不是原本開發的team要補unit test 感覺困難重重95F 08/29 04:32
推 : 看起來像是剛出社會，怎麼會一週才發現方向錯誤
我們公司的Unit Test是開發者要自己寫
因為如果寫的方式不好測試，代表你需要重構96F 08/29 08:19
我們公司的Unit Test是開發者要自己寫
因為如果寫的方式不好測試，代表你需要重構96F 08/29 08:19
噓 : 你要瞎搞可以在自己的side project搞99F 08/29 08:28
推 : 強烈建議新人們要認真看看 brucetu大 講的內容
溝通一直都是在這行業無法順利的最大問題100F 08/29 08:30
溝通一直都是在這行業無法順利的最大問題100F 08/29 08:30
→ : 兄弟 你是錯了 而且都已經要2026了 這種小問題問AI就好..https://i.meee.com.tw/qxPBcX1.png
https://i.meee.com.tw/ORkH9Yt.png102F 08/29 09:34
https://i.meee.com.tw/ORkH9Yt.png102F 08/29 09:34
![[圖]](https://i.meee.com.tw/qxPBcX1.png)
![[圖]](https://i.meee.com.tw/ORkH9Yt.png)
噓 : 沒有e2e前寫unit大多是在自慰105F 08/29 11:00
→ : 抱歉，我可能問ai的方式有問題，我在po文前有把文章餵給ai，他是認同我這篇文章的看法，導致我錯誤的認知，之後改進我問的方式
https://i.imgur.com/wNEFEPe.png106F 08/29 11:20
https://i.imgur.com/wNEFEPe.png106F 08/29 11:20
![[圖]](https://i.imgur.com/wNEFEPeh.png)
推 : 開發者自己寫UT才合理吧..110F 08/29 11:29
→ : 對，這也是我看到的，但是我被排除在開發者之外，我只是專門來幫忙unit test 的，然後又因為公司第一次導入，所以公司大家其實都沒有很確定怎麼做111F 08/29 11:33
推 : 如果你說的屬實 奉勸你快逃 叫你寫ut然後被排除開發者外先不說測的邏輯對不對 你光了解code就得浪費一堆時間吧還有就像大家說的 問清楚要做什麼 不是糾結名詞114F 08/29 13:37
--