作者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/m.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