作者alan8656 (跌倒摔一跤)
看板Soft_Job
標題[請益] 單元測試用這樣的方式進行合理嗎?
時間Thu Aug 28 19:43:28 2025
最近被分配到要去做單元測試Unit test，然後我開始研究某V公司的測試工具，討論編譯
設定、trace32等模擬器如何運行。
然後大概過一個禮拜，研究有點卡頓，因為我第一次用單元測試，而且我不是負責那個專
案的程式專寫。所以遇到一些link error有在詢問V公司解決。
這時負責這個專案的程式擔當來看我怎麼弄那麼久，然後跟我說，這個不需要設定什麼編
譯。
????!!!!我的認知單元測試不是就是動態測試的一種，怎麼可能不用做編譯的設定。
繼續詢問下他說不會直接跑在target上測，也不用到模擬器trace32，直接用一般的g++編
譯器在電腦上跑就可以了，我們只是要"測邏輯"而已。
我有點半信半疑，覺得這個方式怪怪的，我看到的單元測試就是需要模擬實機，所以會需
要用到類似trace32這種模擬器，V公司的人也是跟我們說用這個。
然後更不可思議的是，他直接拿出一包程式，不是原本的專案程式，是經過他"整理過"的
專案程式，替除掉QT、freeRTOS...等等，剩下的程式型態類似於pseudocode的形式，他
說這樣比較好編得過，然後可以測試程式邏輯。
????!!!!是這樣子?這跟已經跟我認知的單元測試不同，這跟測試的概念也相違背了吧。
測試的目的是要"拿真的東西，去模擬的環境測試"，拿人為修過的程式下去測的意義是?
我現在看到單元測試的幾個點
1.屬於動態測試的一種，嵌入式系統可使用模擬器進行測試
2.改完程式當下可以馬上看到設定好的測試結果
3.好的單元測試可以能夠完全自動化
即使我是第一次接觸單元測試，我怎麼看他叫我做的方法都不可能是正確的單元測試，然
後用手動整理過的程式下去測試是哪招?
我有提出質疑，他們可能覺得，客戶就是要看報告，如果要做比較正確的單元測試之後在
其他比較簡單的機種上面執行。
我真的不知道該說什麼，因為我沒有很資深，在這方面也不是了解很多，看看各位的想法
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 115.43.108.100 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1756381410.A.DDC.html
1F：→ nh60211as: 可以不用糾結於名稱是什麼，問清楚目標就好 08/28 19:51
2F：→ nh60211as: 但是個人經驗在PC邏輯對不代表在板子上跑的就沒問題 08/28 19:52
3F：→ alan8656: 現階段的目的應該就真的只是要交一個報告給客戶看，這08/28 19:57
4F：→ alan8656: 個單元測試是客戶要求我們做才開始做的，這是本公司第08/28 19:57
5F：→ alan8656: 一個開始做單元測試的專案 08/28 19:57
6F：推 yamakazi: 我們單元測試指的是google gtest，專門測函數的 08/28 20:00
7F：推 strlen: 不要懷疑 單元測試就是只測邏輯08/28 20:02
8F：推 wulouise: unit test不用管硬體，只是測邏輯，你想測的單元是什麼08/28 20:44
9F：推 guanting886: 你的業主想要你們交Unit Test 報告確定邏輯沒問題就08/28 20:51
10F：→ guanting886: 好，而你想要免費送到Integration/ System Test之上08/28 20:51
11F：→ guanting886: 我是沒什麼意見 啊你還有時間在那裡摸ㄇ08/28 20:51
12F：推 s0914714: 想辦法讓覆蓋率高一點就好啦 至少能交差 08/28 20:53
13F：噓 accessdenied: 你對單元測試的認知是錯的，但他的做法也不算正確。08/28 21:06
14F：→ accessdenied: 單元測試要能切除所有的相依性，但事先沒有想過這08/28 21:06
15F：→ accessdenied: 件事，等成品都已經寫成一拖義大利麵之後才開始弄 08/28 21:06
16F：→ accessdenied: 單元測試，是非常困難的！所以他的做法算是不得已08/28 21:06
17F：→ accessdenied: 的折衷辦法。08/28 21:06
18F：噓 B0988698088: 第一次用可不可以就閉嘴聽負責人就好？ 是他負責又 08/28 21:33
19F：→ B0988698088: 不是你負責08/28 21:33
20F：→ indexcome: 你認知是錯的，UT 只需要管 input output , 所以你餵08/28 22:51
21F：→ indexcome: 進去的是假資料也無所謂。08/28 22:51
22F：→ alan8656: 假資料我覺得沒問題，但是我比較有疑慮的是他把要測試 08/28 22:58
23F：→ alan8656: 的程式修改後才去測這件事情。就像模擬考，考試是假的 08/28 22:58
24F：→ alan8656: ，可是人要是真的，這是我的想法 08/28 22:58
25F：→ wuyiulin: 我覺得他講的比較對，你講的還考慮 RTOS 有點接近整合08/28 23:13
26F：→ wuyiulin: 測試08/28 23:13
27F：→ wuyiulin: 然後就我的經驗，基本上UT就是邏輯通就好，有可能用什 08/28 23:15
28F：→ wuyiulin: 麼套件你板子上沒有的，那就是整合的事情 08/28 23:15
29F：→ wuyiulin: 這邊 V公司不是寫程式給你的，他是提供測試軟體的廠商08/28 23:17
30F：→ wuyiulin: 吧？你程式自己公司寫的自己公司要負責啊，為什麼會想08/28 23:17
31F：→ wuyiulin: 問 V公司？08/28 23:17
32F：→ alan8656: 當初不確定問題是出在程式還是工具上08/28 23:28
33F：推 lturtsamuel: 單元測試就是要測邏輯 你還牽扯環境不就是整合測試？08/28 23:28
34F：→ lturtsamuel: 程式修改也不是不行 弄個編譯選項條件編譯就好 盡量 08/28 23:30
35F：→ lturtsamuel: 貼近不是一定要一百趴貼近 現實沒那麼完美的08/28 23:30
36F：→ lturtsamuel: 他這做法當然也不太對 他如果有辦法把邏輯抽出來變成08/28 23:32
37F：→ lturtsamuel: 獨立一包 理應把這包變成函式庫讓主程式用才對 08/28 23:32
38F：→ alan8656: 感謝大家的指點，這樣看起來unit test要做的好，程式設08/28 23:44
39F：→ alan8656: 計一開始就要想到每個函式的獨立運作性08/28 23:44
40F：推 brucetu: 你們兩個都有錯 你說的是整合測試 08/28 23:45
41F：→ brucetu: 我要更正一下 你同事有可能是對的08/28 23:46
42F：→ brucetu: 如果他是把邏輯抽出來 mock掉不需要測的部分 而且他沒有08/28 23:47
43F：→ brucetu: 亂寫測試 那你同事就是對的08/28 23:47
44F：→ brucetu: 完美的做法是包成函式庫。礙於現實考量，我認為把程式碼 08/28 23:48
45F：→ brucetu: 複製出來另一個專案，做好mock測過沒問題這個做法可以接 08/28 23:49
46F：→ brucetu: 受，只是你以後要經常維護兩邊的東西一致會很辛苦也很容 08/28 23:49
47F：→ brucetu: 易出問題08/28 23:49
48F：→ brucetu: 然後你真的沒必要這樣埋頭幹半天才發現根本弄錯方向，你08/28 23:55
49F：→ brucetu: 應該像AI一樣做事，你在第一時間就該釐清你打算做什麼， 08/28 23:55
50F：→ brucetu: 條列出來，拿著你的工作計畫去找負責人確認：「我打算這 08/28 23:55
51F：→ brucetu: 樣這樣做，你看有沒有問題，沒有問題我就照這樣執行，有08/28 23:55
52F：→ brucetu: 遇到問題再討論。」埋頭苦幹最後根本做錯方向就是為什麼08/28 23:55
53F：→ brucetu: 資深員工寧願把東西丟給AI做也不想帶新人的原因。你過去08/28 23:55
54F：→ brucetu: 一週的表現就像一個收到請求之後要耗費長達一週才回應而08/28 23:55
55F：→ brucetu: 且還完全搞錯方向的AI。建議不要再繼續用這種埋頭自幹的08/28 23:55
56F：→ brucetu: 方式做事 08/28 23:55
57F：→ alan8656: 了解，我可能也要再去搞清楚整合測試以及單元測試的差08/29 00:06
58F：→ alan8656: 別。不要埋頭苦幹要先釐清問題這個道理我知道，但是什08/29 00:06
59F：→ alan8656: 麼都不懂就馬上問人也是問不出東西，我通常是先做一點 08/29 00:06
60F：→ alan8656: 有遇到問題再問，我也還在抓這之間的平衡點。08/29 00:06
61F：→ brucetu: 關於如何拿捏問問題的時機，我想補充說明清楚一點，你需08/29 00:47
62F：→ brucetu: 要做的是回報你的狀態，回報狀態不是發問，不要求對方花 08/29 00:47
63F：→ brucetu: 時間給你解答，只是讓他掌握你的動向，不用擔心造成對方08/29 00:47
64F：→ brucetu: 反感。你可以至少兩天一次主動寄信告訴前輩你正在做什麼08/29 00:47
65F：→ brucetu: ，或者預計要怎麼做，他就會發現你卡在錯誤的方向。我同08/29 00:47
66F：→ brucetu: 事每天甚至一天兩次回報狀態我覺得完全沒問題。這不是要 08/29 00:47
67F：→ brucetu: 你去問對方「我該怎麼做」而是告知對方「我的計畫是這樣 08/29 00:47
68F：→ brucetu: 」所以你不用擔心這樣的訊息會打擾對方，沒有大問題對方 08/29 00:47
69F：→ brucetu: 通常瞄一眼就關掉了，方向很歪的話就會跟你溝通。通常帶08/29 00:47
70F：→ brucetu: 你的人不想讓自己顯得像控制狂天天盯你在做什麼，你不主08/29 00:47
71F：→ brucetu: 動回報就會演變成你辛苦白忙一週還被認定能力有問題。以 08/29 00:47
72F：→ brucetu: 你的例子你可能在第一天告訴前輩：「我正在處理oo的單元 08/29 00:47
73F：→ brucetu: 測試，需要花一些時間研究trace32的參數。」第二天告訴他08/29 00:47
74F：→ brucetu: ：「早安，關於oo的單元測試，由於編譯有問題，我正在聯08/29 00:47
75F：→ brucetu: 絡廠商。」如果這是對的路徑他兩秒就關掉你的郵件了，不08/29 00:47
76F：→ brucetu: 會造成負擔。記得每一封信要簡短清楚寫明你正在做的是哪08/29 00:47
77F：→ brucetu: 個模組，對方可沒那個腦容量記得每個人是負責什麼部份。08/29 00:47
78F：→ brucetu: 就算你對一個工作項目一頭霧水至少你也寫得出「早安，進 08/29 00:47
79F：→ brucetu: 度回報，我今天要研究哪一塊程式碼」或是「我正在聯絡誰08/29 00:47
80F：→ brucetu: 」。只要你別直球叫對方告訴你答案，讓他可以無壓力的已08/29 00:48
81F：→ brucetu: 讀不回，就不會踩到對方的雷。 08/29 00:48
82F：推 s0914714: 真正的問題是叫你做unit test 但你沒做過就直接下去做08/29 00:52
83F：→ s0914714: 早期要導unit test 主管還特地開課教學讓大家有共識08/29 00:53
84F：→ s0914714: 畢竟這種方法論還是有很多流派 所以大家有共識很重要 08/29 00:54
85F：→ ichunlai: 單元測試也要教喔...經典書籍就 unit testing principle08/29 01:00
86F：→ ichunlai: s practices and patterns，自己看08/29 01:00
87F：推 hackfox: 你扯到系統測試了08/29 01:30
88F：推 viper9709: brucetu講得不錯 08/29 01:39
89F：→ strlen: 不過呢 我覺得啦 等你認真研究UT一陣子之後呢 就會跟上面 08/29 01:44
90F：→ strlen: 報 我們這葛專案不要搞UT好不好 下一個新專案在搞吧 XD 08/29 01:45
91F：→ strlen: 為什麼要UT？其中一個最重要的理由就是強迫你解耦程式08/29 01:45
92F：→ strlen: 強迫你在寫程式時把邏輯部份抽離 因為這樣才能測試08/29 01:46
93F：→ strlen: 然後抽離時就會發現 整個系統架構就要大改 然後就....... 08/29 01:50
94F：推 a731977: mock data在單元測試很常見喔，看結果應該是你誤會 08/29 01:52
95F：→ poison5566: 而且不是原本開發的team要補unit test 感覺困難重重08/29 04:32
96F：推 Deltak: 看起來像是剛出社會，怎麼會一週才發現方向錯誤08/29 08:19
97F：→ Deltak: 我們公司的Unit Test是開發者要自己寫08/29 08:22
98F：→ Deltak: 因為如果寫的方式不好測試，代表你需要重構08/29 08:22
99F：噓 panda04056: 你要瞎搞可以在自己的side project搞08/29 08:28
100F：推 selph1120: 強烈建議新人們要認真看看 brucetu大 講的內容 08/29 08:30
101F：→ selph1120: 溝通一直都是在這行業無法順利的最大問題08/29 08:31
102F：→ kurtsgm: 兄弟 你是錯了 而且都已經要2026了 這種小問題問AI就好..08/29 09:34
105F：噓 MoonCode: 沒有e2e前寫unit大多是在自慰08/29 11:00
106F：→ alan8656: 抱歉，我可能問ai的方式有問題，我在po文前有把文章餵 08/29 11:20
107F：→ alan8656: 給ai，他是認同我這篇文章的看法，導致我錯誤的認知，08/29 11:20
108F：→ alan8656: 之後改進我問的方式08/29 11:20
110F：推 ppc: 開發者自己寫UT才合理吧.. 08/29 11:29
111F：→ alan8656: 對，這也是我看到的，但是我被排除在開發者之外，我只 08/29 11:33
112F：→ alan8656: 是專門來幫忙unit test 的，然後又因為公司第一次導入 08/29 11:33
113F：→ alan8656: ，所以公司大家其實都沒有很確定怎麼做08/29 11:33
114F：推 s0914714: 如果你說的屬實 奉勸你快逃 叫你寫ut然後被排除開發者外08/29 13:37
115F：→ s0914714: 先不說測的邏輯對不對 你光了解code就得浪費一堆時間吧 08/29 13:38
116F：推 s0914714: 還有就像大家說的 問清楚要做什麼 不是糾結名詞 08/29 13:46
117F：推 ck237: 單元測試跟整合測試差很多也，你是不是搞不懂啊？08/29 15:02
118F：→ ck237: 單元測試就很簡單，檢查有沒有無效判定式或例外，說白的就08/29 15:05
119F：→ ck237: 是檢查有沒有開發者不小心寫了一個進不去的判定式而已，只08/29 15:05
120F：→ ck237: 要確保預設參數會出現相符的結果或例外，就是正確的08/29 15:05
121F：→ strlen: 真的是大開眼界 居然有公司 開發一組人 寫UI另一組人 XDDD08/29 15:11
122F：→ strlen: 我der老天 還不快跑？ 08/29 15:11
123F：→ strlen: *UT08/29 15:11
124F：→ brucetu: 不覺得單元測試很簡單 需求沒有被定義清楚的函式很有可08/29 15:42
125F：→ brucetu: 能做了單元測試也是白做。同理，負責寫單元測試的人如果 08/29 15:42
126F：→ brucetu: 不清楚被測物的正確行為是什麼，那測也是白測。交報告的08/29 15:42
127F：→ brucetu: 話只要每個路徑都有走到就可以了沒錯，但每個路徑都有走08/29 15:42
128F：→ brucetu: 到不表示那個函數是對的，最後老闆會問你：啊不是有測試 08/29 15:42
129F：→ brucetu: ？啊測了一樣會出問題？那幹嘛浪費時間寫測試？08/29 15:42
130F：→ brucetu: 很多時候測試程式碼本身就是錯的 只是在浪費時間而已08/29 15:44
131F：→ labbat: 開(ㄋㄧˋ)發(ㄒㄧㄤˋ)產(ㄍㄨㄥ)品(ㄔㄥˊ)的時候測試程08/29 15:56
132F：→ labbat: 式怎麼會浪放時間，一切的需求都是從測試程式定義出來的 08/29 15:57
133F：→ labbat: 打錯字，浪費 08/29 15:57
134F：→ labbat: 如果有問題，那表示是需求的客製化就要回頭問規格誰訂的 08/29 15:59
135F：→ brucetu: 如果單元測試寫錯了，我們會在整合測試發現問題。如果整08/29 16:01
136F：→ brucetu: 合測試寫錯了，使用者會發現問題。所以很多時候單元測試08/29 16:01
137F：→ brucetu: 是多餘的 我只是想表達這個常見的狀況 08/29 16:01
138F：→ labbat: 多於要看代價唄，原則上單元測試是相當廉價的然後整合測試 08/29 16:02
139F：→ labbat: 甚至是系統測試在資源消耗上是相當昂貴的08/29 16:03
140F：→ labbat: 尤其是在掛勾一堆外掛和除錯套件，系統測試就會天荒地老08/29 16:04
141F：→ labbat: 當然我放著給使用者當測試，就是死道友的概念08/29 16:05
142F：推 s0914714: 單元測試比較像開發時期的保護傘 避免改完bug又被改回來08/29 17:16
143F：推 Deltak: 單元測試很好用啊，怕東西改壞，就先寫UT08/29 19:27
144F：推 EricTao: 不同意100樓 因為我覺得老人也要看w 08/29 19:32
145F：推 EricTao: 單元測試至少能幫助debug，就算寫不完全或根本測錯，至08/29 19:35
146F：→ EricTao: 少你看得到已經測過的部分，不用重新通靈08/29 19:35
147F：→ newhandfun: b大回得不錯，可以回文造福類似的人 08/29 19:38
148F：推 NDark: brucetu是對的 測試老問題了 規格不清楚的東西沒辦法測08/29 19:46
149F：→ wuyiulin: 我支持單元測試很重要，如果整合系統跟做功能的人不同08/29 23:47
150F：→ wuyiulin: 更重要 08/29 23:47
151F：→ wuyiulin: 因為這樣才知道到底是需求開錯，還是程式寫錯08/29 23:47
152F：→ wuyiulin: 這是管理工作氛圍很重要的一點，做系統的資深工程師或08/29 23:49
153F：→ wuyiulin: 是主管要扛起決策責任，不能整合出問題跑去怪做功能的08/29 23:49
154F：→ wuyiulin: 新人 08/29 23:49
155F：→ wuyiulin: 丟給使用者做整合測試，如果是內部需求，那情境可能還 08/29 23:51
156F：→ wuyiulin: 可以；如果是客戶，這情況不妙 08/29 23:51
157F：→ brucetu: 講是這樣講 誰家產品沒被客戶測出一堆問題的..08/30 13:58
158F：→ labbat: 退一萬步來說交給客戶檢查問題了，但客戶又不會端到嘴前08/30 17:08
159F：→ labbat: 餵食出錯的根本原因，也不會教怎麼改成沒問題的功能唄 08/30 17:08
感謝各位大大給的建議
簡單用GPT總結如下
https://i.imgur.com/uzCXlUT.png
很感謝brucetu給的意見。我會再好好參考!
另外我要澄清一些對我的一些批評。
1.這個公司第一次導入unit test，那位資深同事雖然比我資深很多沒錯，但是他在這間
沒做過UT的公司做10幾年以上，我可以合理推測他也沒有實際做過UT，然後看到他的方式
跟我google和問ChatGPT的結果相差不少。因為我也沒有實際經驗判斷他的方法正不正確
，所以我最後想說丟上來給大家罵罵也好，了解一下實務上UT會怎麼進行
2.關於溝通的部分，我要替自己辯護一下，溝通也是要看對象看場合。我以前在前公司的
時候，覺得溝通就比這邊順利，也許那邊的人比較契合，或是說上司指令比較明確。溝通
的方式對人和在不同場合會有所不同，在這間公司我還在調整要怎麼溝通會比較順利
關於UT這件事情我整理一下我看下來的心得：
1.公司第一次要做UT，軟體部沒有說明UT的相關規劃，然後叫一個非該專案設計的工程師
來替其他開發者做UT。這點看大家的留言很多認為這公司做的不太對，好幾位大大叫我說
可以逃了....
2.看起來UT是測邏輯沒錯，但是各位大大提到事前應該要做好規劃，看到大大提到抽出邏
輯、mock等方式，確實很合理。但是我看那位前輩的實作的方式，我看程式的感覺不是那
麼經過規劃的方式...，感覺只是另外用手動複製出專案內程式，然後手動剃除其他相依
性程式，剩下接近pseudocode的東西。可能邏輯是一樣的，但是未來改動程式還要另外維
護，也很難保證中間手動改動的邏輯不會變。
3.我會再多多了解整合測試、單元測試、端對端測試之間的差異
感謝大家的留言，讓我更懂得各種軟體測試的實際方向，感謝大家!
※ 編輯: alan8656 (115.43.108.100 臺灣), 08/30/2025 19:10:17
※ 編輯: alan8656 (27.51.0.83 臺灣), 08/30/2025 19:17:07
※ 編輯: alan8656 (27.51.0.83 臺灣), 08/30/2025 19:19:24
160F：推 s0914714: 你前輩的做法的確是錯的 怎麼是拔掉相依的程式 08/30 22:38
161F：→ s0914714: 每次改版都要自己手動拔 不僅太累而且也可能出錯 08/30 22:38
162F：→ s0914714: 不過職場百百種啦 如果想在原公司生存就聽主管的吧XD 08/30 22:40
163F：→ s0914714: 工作本來就不是做對的事 是做主管(業主)想要的事 08/30 22:41
164F：推 viper9709: 推工作是做業主想要的事XD 08/31 01:08
165F：推 rahit: 看你為誰服務 08/31 15:27
166F：→ rahit: 如果教你的是你老闆聽就是了 08/31 15:27
167F：→ acgotaku: 不要神話甚至依賴單元測試 把他當測試一部分就好 09/05 11:25
168F：→ acgotaku: 講難聽點一堆產品沒測也上線跑爽爽 有測也不一定不會爆 09/05 11:26
169F：→ acgotaku: 尤其軟韌跟硬體整合太大 主管沒 care 就他覺得會爆也不 09/05 11:29
170F：→ acgotaku: 會是你這環節爆 issue 09/05 11:30
171F：推 selph1120: 各種測試之間的差異, 你看文章看影片或去上課, 都很難 09/08 10:06
172F：→ selph1120: 真正理解各自帶給你的系統的益處是什麼, 我個人覺得這 09/08 10:06
173F：→ selph1120: 是需要經驗累積的 09/08 10:06
174F：→ selph1120: 社群上各種概念或原則性的教學, 建議你都把它當作參考 09/08 10:07
175F：→ selph1120: 就好, 因為每個人負責的系統跟情境各自不同 09/08 10:08
176F：→ selph1120: 你碰到的case讓你覺得困惑, 就問清楚為什麼要這樣做 09/08 10:09
177F：→ selph1120: 釐清問題點在哪, 再去思考有沒有優化的空間就好 09/08 10:09
178F：→ selph1120: 若case與你認知的"原則"或"概念"不同, 有時不代表它有 09/08 10:10
179F：→ selph1120: 問題, 大多都是因為有一些限制存在 09/08 10:11
180F：→ selph1120: 有時候當下不合你的"概念"或"原則"的做法, 其實是最適 09/08 10:11
181F：→ selph1120: 合該情境的最佳解 09/08 10:12
182F：→ selph1120: 看過太多新人滿嘴都是頭頭是道的原則, 無視實務上各式 09/08 10:14
183F：→ selph1120: 各樣五花八門的情境 09/08 10:14