最近被分配到要去做單元測試Unit test，然後我開始研究某V公司的測試工具，討論編譯
設定、trace32等模擬器如何運行。
然後大概過一個禮拜，研究有點卡頓，因為我第一次用單元測試，而且我不是負責那個專
案的程式專寫。所以遇到一些link error有在詢問V公司解決。
這時負責這個專案的程式擔當來看我怎麼弄那麼久，然後跟我說，這個不需要設定什麼編
譯。
????!!!!我的認知單元測試不是就是動態測試的一種，怎麼可能不用做編譯的設定。
繼續詢問下他說不會直接跑在target上測，也不用到模擬器trace32，直接用一般的g++編
譯器在電腦上跑就可以了，我們只是要"測邏輯"而已。
我有點半信半疑，覺得這個方式怪怪的，我看到的單元測試就是需要模擬實機，所以會需
要用到類似trace32這種模擬器，V公司的人也是跟我們說用這個。
然後更不可思議的是，他直接拿出一包程式，不是原本的專案程式，是經過他"整理過"的
專案程式，替除掉QT、freeRTOS...等等，剩下的程式型態類似於pseudocode的形式，他
說這樣比較好編得過，然後可以測試程式邏輯。
????!!!!是這樣子?這跟已經跟我認知的單元測試不同，這跟測試的概念也相違背了吧。
測試的目的是要"拿真的東西，去模擬的環境測試"，拿人為修過的程式下去測的意義是?
我現在看到單元測試的幾個點
1.屬於動態測試的一種，嵌入式系統可使用模擬器進行測試
2.改完程式當下可以馬上看到設定好的測試結果
3.好的單元測試可以能夠完全自動化
即使我是第一次接觸單元測試，我怎麼看他叫我做的方法都不可能是正確的單元測試，然
後用手動整理過的程式下去測試是哪招?
我有提出質疑，他們可能覺得，客戶就是要看報告，如果要做比較正確的單元測試之後在
其他比較簡單的機種上面執行。
我真的不知道該說什麼，因為我沒有很資深，在這方面也不是了解很多，看看各位的想法

可以不用糾結於名稱是什麼，問清楚目標就好但是個人經驗在PC邏輯對不代表在板子上跑的就沒問題

現階段的目的應該就真的只是要交一個報告給客戶看，這個單元測試是客戶要求我們做才開始做的，這是本公司第一個開始做單元測試的專案

我們單元測試指的是google gtest，專門測函數的

不要懷疑 單元測試就是只測邏輯

unit test不用管硬體，只是測邏輯，你想測的單元是什麼

你的業主想要你們交Unit Test 報告確定邏輯沒問題就好，而你想要免費送到Integration/ System Test之上我是沒什麼意見 啊你還有時間在那裡摸ㄇ

想辦法讓覆蓋率高一點就好啦 至少能交差

你對單元測試的認知是錯的，但他的做法也不算正確。單元測試要能切除所有的相依性，但事先沒有想過這件事，等成品都已經寫成一拖義大利麵之後才開始弄單元測試，是非常困難的！所以他的做法算是不得已的折衷辦法。

第一次用可不可以就閉嘴聽負責人就好？ 是他負責又不是你負責

你認知是錯的，UT 只需要管 input output , 所以你餵進去的是假資料也無所謂。

假資料我覺得沒問題，但是我比較有疑慮的是他把要測試的程式修改後才去測這件事情。就像模擬考，考試是假的，可是人要是真的，這是我的想法

我覺得他講的比較對，你講的還考慮 RTOS 有點接近整合測試

當初不確定問題是出在程式還是工具上

單元測試就是要測邏輯 你還牽扯環境不就是整合測試？程式修改也不是不行 弄個編譯選項條件編譯就好 盡量貼近不是一定要一百趴貼近 現實沒那麼完美的他這做法當然也不太對 他如果有辦法把邏輯抽出來變成獨立一包 理應把這包變成函式庫讓主程式用才對

感謝大家的指點，這樣看起來unit test要做的好，程式設計一開始就要想到每個函式的獨立運作性

你們兩個都有錯 你說的是整合測試我要更正一下 你同事有可能是對的如果他是把邏輯抽出來 mock掉不需要測的部分 而且他沒有亂寫測試 那你同事就是對的完美的做法是包成函式庫。礙於現實考量，我認為把程式碼複製出來另一個專案，做好mock測過沒問題這個做法可以接受，只是你以後要經常維護兩邊的東西一致會很辛苦也很容易出問題然後你真的沒必要這樣埋頭幹半天才發現根本弄錯方向，你應該像AI一樣做事，你在第一時間就該釐清你打算做什麼，條列出來，拿著你的工作計畫去找負責人確認：「我打算這樣這樣做，你看有沒有問題，沒有問題我就照這樣執行，有遇到問題再討論。」埋頭苦幹最後根本做錯方向就是為什麼資深員工寧願把東西丟給AI做也不想帶新人的原因。你過去一週的表現就像一個收到請求之後要耗費長達一週才回應而且還完全搞錯方向的AI。建議不要再繼續用這種埋頭自幹的方式做事

了解，我可能也要再去搞清楚整合測試以及單元測試的差別。不要埋頭苦幹要先釐清問題這個道理我知道，但是什麼都不懂就馬上問人也是問不出東西，我通常是先做一點有遇到問題再問，我也還在抓這之間的平衡點。

關於如何拿捏問問題的時機，我想補充說明清楚一點，你需要做的是回報你的狀態，回報狀態不是發問，不要求對方花時間給你解答，只是讓他掌握你的動向，不用擔心造成對方反感。你可以至少兩天一次主動寄信告訴前輩你正在做什麼，或者預計要怎麼做，他就會發現你卡在錯誤的方向。我同事每天甚至一天兩次回報狀態我覺得完全沒問題。這不是要你去問對方「我該怎麼做」而是告知對方「我的計畫是這樣」所以你不用擔心這樣的訊息會打擾對方，沒有大問題對方通常瞄一眼就關掉了，方向很歪的話就會跟你溝通。通常帶你的人不想讓自己顯得像控制狂天天盯你在做什麼，你不主動回報就會演變成你辛苦白忙一週還被認定能力有問題。以你的例子你可能在第一天告訴前輩：「我正在處理oo的單元測試，需要花一些時間研究trace32的參數。」第二天告訴他：「早安，關於oo的單元測試，由於編譯有問題，我正在聯絡廠商。」如果這是對的路徑他兩秒就關掉你的郵件了，不會造成負擔。記得每一封信要簡短清楚寫明你正在做的是哪個模組，對方可沒那個腦容量記得每個人是負責什麼部份。就算你對一個工作項目一頭霧水至少你也寫得出「早安，進度回報，我今天要研究哪一塊程式碼」或是「我正在聯絡誰」。只要你別直球叫對方告訴你答案，讓他可以無壓力的已讀不回，就不會踩到對方的雷。

真正的問題是叫你做unit test 但你沒做過就直接下去做早期要導unit test 主管還特地開課教學讓大家有共識畢竟這種方法論還是有很多流派 所以大家有共識很重要

單元測試也要教喔...經典書籍就 unit testing principles practices and patterns，自己看

你扯到系統測試了

brucetu講得不錯

不過呢 我覺得啦 等你認真研究UT一陣子之後呢 就會跟上面報 我們這葛專案不要搞UT好不好 下一個新專案在搞吧 XD為什麼要UT？其中一個最重要的理由就是強迫你解耦程式強迫你在寫程式時把邏輯部份抽離 因為這樣才能測試然後抽離時就會發現 整個系統架構就要大改 然後就.......

mock data在單元測試很常見喔，看結果應該是你誤會

而且不是原本開發的team要補unit test 感覺困難重重

看起來像是剛出社會，怎麼會一週才發現方向錯誤我們公司的Unit Test是開發者要自己寫因為如果寫的方式不好測試，代表你需要重構

你要瞎搞可以在自己的side project搞

強烈建議新人們要認真看看 brucetu大 講的內容溝通一直都是在這行業無法順利的最大問題

兄弟 你是錯了 而且都已經要2026了 這種小問題問AI就好..https://i.meee.com.tw/qxPBcX1.pnghttps://i.meee.com.tw/ORkH9Yt.png

沒有e2e前寫unit大多是在自慰

抱歉，我可能問ai的方式有問題，我在po文前有把文章餵給ai，他是認同我這篇文章的看法，導致我錯誤的認知，之後改進我問的方式https://i.imgur.com/wNEFEPe.png

開發者自己寫UT才合理吧..

對，這也是我看到的，但是我被排除在開發者之外，我只是專門來幫忙unit test 的，然後又因為公司第一次導入，所以公司大家其實都沒有很確定怎麼做

如果你說的屬實 奉勸你快逃 叫你寫ut然後被排除開發者外先不說測的邏輯對不對 你光了解code就得浪費一堆時間吧還有就像大家說的 問清楚要做什麼 不是糾結名詞

單元測試跟整合測試差很多也，你是不是搞不懂啊？單元測試就很簡單，檢查有沒有無效判定式或例外，說白的就是檢查有沒有開發者不小心寫了一個進不去的判定式而已，只要確保預設參數會出現相符的結果或例外，就是正確的

真的是大開眼界 居然有公司 開發一組人 寫UI另一組人 XDDD我der老天 還不快跑？*UT

不覺得單元測試很簡單 需求沒有被定義清楚的函式很有可能做了單元測試也是白做。同理，負責寫單元測試的人如果不清楚被測物的正確行為是什麼，那測也是白測。交報告的話只要每個路徑都有走到就可以了沒錯，但每個路徑都有走到不表示那個函數是對的，最後老闆會問你：啊不是有測試？啊測了一樣會出問題？那幹嘛浪費時間寫測試？很多時候測試程式碼本身就是錯的 只是在浪費時間而已

開(ㄋㄧˋ)發(ㄒㄧㄤˋ)產(ㄍㄨㄥ)品(ㄔㄥˊ)的時候測試程式怎麼會浪放時間，一切的需求都是從測試程式定義出來的打錯字，浪費如果有問題，那表示是需求的客製化就要回頭問規格誰訂的

如果單元測試寫錯了，我們會在整合測試發現問題。如果整合測試寫錯了，使用者會發現問題。所以很多時候單元測試是多餘的 我只是想表達這個常見的狀況

多於要看代價唄，原則上單元測試是相當廉價的然後整合測試甚至是系統測試在資源消耗上是相當昂貴的尤其是在掛勾一堆外掛和除錯套件，系統測試就會天荒地老當然我放著給使用者當測試，就是死道友的概念

單元測試比較像開發時期的保護傘 避免改完bug又被改回來

單元測試很好用啊，怕東西改壞，就先寫UT

不同意100樓 因為我覺得老人也要看w單元測試至少能幫助debug，就算寫不完全或根本測錯，至少你看得到已經測過的部分，不用重新通靈

b大回得不錯，可以回文造福類似的人

brucetu是對的 測試老問題了 規格不清楚的東西沒辦法測

我支持單元測試很重要，如果整合系統跟做功能的人不同更重要因為這樣才知道到底是需求開錯，還是程式寫錯這是管理工作氛圍很重要的一點，做系統的資深工程師或是主管要扛起決策責任，不能整合出問題跑去怪做功能的新人丟給使用者做整合測試，如果是內部需求，那情境可能還可以；如果是客戶，這情況不妙

講是這樣講 誰家產品沒被客戶測出一堆問題的..

退一萬步來說交給客戶檢查問題了，但客戶又不會端到嘴前餵食出錯的根本原因，也不會教怎麼改成沒問題的功能唄

你前輩的做法的確是錯的 怎麼是拔掉相依的程式每次改版都要自己手動拔 不僅太累而且也可能出錯不過職場百百種啦 如果想在原公司生存就聽主管的吧XD工作本來就不是做對的事 是做主管(業主)想要的事

推工作是做業主想要的事XD

看你為誰服務如果教你的是你老闆聽就是了

不要神話甚至依賴單元測試 把他當測試一部分就好講難聽點一堆產品沒測也上線跑爽爽 有測也不一定不會爆尤其軟韌跟硬體整合太大 主管沒 care 就他覺得會爆也不會是你這環節爆 issue

各種測試之間的差異, 你看文章看影片或去上課, 都很難真正理解各自帶給你的系統的益處是什麼, 我個人覺得這是需要經驗累積的社群上各種概念或原則性的教學, 建議你都把它當作參考就好, 因為每個人負責的系統跟情境各自不同你碰到的case讓你覺得困惑, 就問清楚為什麼要這樣做釐清問題點在哪, 再去思考有沒有優化的空間就好若case與你認知的"原則"或"概念"不同, 有時不代表它有問題, 大多都是因為有一些限制存在有時候當下不合你的"概念"或"原則"的做法, 其實是最適合該情境的最佳解看過太多新人滿嘴都是頭頭是道的原則, 無視實務上各式各樣五花八門的情境