最近被分配到要去做单元测试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