作者shane87123 (阳光大肥宅)
看板Soft_Job
标题[讨论] Unit test 的撰写请益
时间Tue Nov 8 18:51:34 2022
先说我对 Unit test 的看法：测试单元（可能是 function）的逻辑是否正确
好，进入正题
小弟最近刚工作，稍微读了一下负责的 project 的程式码後，
要开始开发 Unit test。
现况是，各个 file (.c) dependency 很重，
常常会有一份 code 内其实呼叫了很多别份 code 的 function，
举例来说
A() {
B();
C();
if (check)
D();
}
族繁不及备载，
而我目前设计有两个方向，
1.
将 B() C() D() 全部 fake ，单纯去测试 A() 的逻辑是否正确
这样做感觉上会比较单纯，一个 test case 只去 test A()，
而且不需要去 include B() C() D() 的 header，
这样一来 build 起来也比较容易，因为 include 那些 header 又会 dependency 到其他档
情况会非常复杂
缺点是 coverage 比较差，B() C() D()要额外去写 test case
2.
直接把他们 include 进来，build failed 就 include，直到 build 过为止
这样的好处是不用去实作 B() C() D() 的 fake，
但就会让整个 unit test 的 dependency 很重
个人偏向1.，毕竟 unit test 就是去测试 function 的逻辑性，
在其他 function 对测试 function 没有 side effect 的情况下（如不会改变某变数的值?
将他们 fake 掉而只是单纯的去 test 该 function 而已
但我第一次接触，不太知道何时应该去 fake (或 mock) 一个 function QQ
我只是有这两种想法，两个其实天差地远XDD
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.25.70.74 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1667904696.A.B26.html
1F：推 vi000246: 你可以先读重构相关的书11/08 18:53
2F：→ GooseLover: 如果模组化有做好，那你1.做得是正确的事情。正常来11/08 19:12
3F：→ GooseLover: 说就是Function跟Process分开测，最後再来个整合测试11/08 19:12
4F：→ GooseLover: 。然後不要抗拒为各别Function写Unittest11/08 19:12
我本来预期就是为个别档案的个别function写unit test，不过不确定这样做是不是有符合u
nit test的特性
5F：推 s06yji3: 单元测试的话111/08 19:15
6F：→ foreverk: 用1吧，如果要测试的function长文章那样，那本来就应该11/08 19:22
7F：→ foreverk: 花时间写BCD的test case11/08 19:22
谢谢各位大大，那我可以放心去fake了
8F：推 s06yji3: 不知道你用什麽语言，通常会有tool帮你拦截dep的function11/08 19:28
9F：→ s06yji3: 然後去呼叫对应的fake function11/08 19:28
应是用google test，没错，他可以去呼叫fake function。这部分的实作应该没什麽问题
10F：推 MoonCode: 对了 不写这个测试会怎样？ 11/08 20:14
※ 编辑: shane87123 (114.25.70.74 台湾), 11/08/2022 20:15:55
11F：→ ssccg: 合起来测也是种测法，只是那就不是unit test了 11/08 21:14
12F：→ angusyu: 专案如果没有在切介面，直接硬fake会写到怀疑人生 11/08 21:24
13F：推 yamakazi: gmock 就是1啊 11/08 22:41
14F：→ yamakazi: gmock gtest框架都有了，你想得到的问题大公司都想到了 11/08 22:42
15F：→ yamakazi: ，直接整套拿去用就好 11/08 22:42
16F：推 drajan: 没切介面就赶快 refactor 没测试的软体能跑吗 11/08 23:01
17F：推 sniper2824: 1 11/08 23:51
18F：推 viper9709: 推二楼 11/08 23:57
19F：推 Lipraxde: 没出问题的 legacy code 就别想着帮别人加 UT 了，顶多 11/09 00:00
20F：→ Lipraxde: 做做整合测试，别把自己搞到怀疑人生 11/09 00:00
21F：推 lovdkkkk: 不确定目前程式的情况, 假如目前程式很乱, 有可能需要先 11/09 00:17
22F：→ lovdkkkk: 做 2 快速加个整合测试, 重构一下, 之後再做 1 11/09 00:17
23F：→ leo08210917: 介面切好 弄懂IoC、DI做mock很快 UT也方便 11/09 01:07
24F：→ leo08210917: 旧的可以用防腐层切开 弄整合测试就好 11/09 01:08
25F：推 prag222: 虽我单元测试没啥经验,但说真的就是程式太鸟才依赖性 11/09 02:21
26F：→ prag222: 太高,相信用物件导向或设计模式都可以切乾净的 11/09 02:21
27F：→ Lipraxde: 只会更糟吧XDDD 11/09 07:22
28F：→ bnd0327: 如果BCD没有被其他函式使用，直接用真的BCD测也无妨 11/09 08:53
29F：推 wulouise: 2不算UT,但是你在refactor前可能会写出2那样的情况 11/09 12:10
30F：→ wulouise: 最好先用test framework测整合测试再来refactor 11/09 12:12
31F：推 andy831020: 绝对是1 最小单元去测试 11/09 15:23
32F：推 lestibournes: 最近也在工作上尝试导入，觉得应该是1。但光mock就 11/09 18:28
33F：→ lestibournes: 一堆东西，还要担心测试把程式码绑死（因为mock/fa 11/09 18:28
34F：→ lestibournes: ke的部分已经明确宣告在测试内），还是先硬着头皮 11/09 18:28
35F：→ lestibournes: 先写了QQ 11/09 18:28
36F：推 CoNsTaR: 切 dependency 用 mock，有测试环境的问题用 fake 11/09 22:33
37F：→ acgotaku: 请善用DI,然後再写的时候尽量将ABC低耦合 确保你分开测 11/10 01:36
38F：→ acgotaku: ABC的时候不需要在mock,做假资料的时候尽量是真实状况 11/10 01:38
39F：推 s8952889: 当然是1吧，如果你今天改B的程式码结果A的单元测试错了 11/10 12:51
40F：→ s8952889: 很奇怪 11/10 12:51
41F：→ s8952889: 不过其实在单元测试的档案写整合测试也是没问题的吧 11/10 12:52