[討論] Unit test 的撰寫請益

作者: shane87123 (陽光大肥宅)   2022-11-08 18:51:34
先說我對 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
作者: vi000246 (Vi)   2022-11-08 18:53:00
你可以先讀重構相關的書
作者: GooseLover (凱因哈特利)   2022-11-08 19:12:00
如果模組化有做好,那你1.做得是正確的事情。正常來說就是Function跟Process分開測,最後再來個整合測試。然後不要抗拒為各別Function寫Unittest
作者: s06yji3 (阿南)   2022-11-08 19:15:00
單元測試的話1
作者: foreverk (文藝青年)   2022-11-08 19:22:00
用1吧,如果要測試的function長文章那樣,那本來就應該花時間寫BCD的test case
作者: s06yji3 (阿南)   2022-11-08 19:28:00
不知道你用什麼語言,通常會有tool幫你攔截dep的function然後去呼叫對應的fake function
作者: MoonCode (MoonCode)   2022-11-08 20:14:00
對了 不寫這個測試會怎樣?
作者: ssccg (23)   2022-11-08 21:14:00
合起來測也是種測法,只是那就不是unit test了
作者: angusyu (〒△〒)   2022-11-08 21:24:00
專案如果沒有在切介面,直接硬fake會寫到懷疑人生
作者: yamakazi (大安吳彥祖)   2022-11-08 22:41:00
gmock 就是1啊gmock gtest框架都有了,你想得到的問題大公司都想到了,直接整套拿去用就好
作者: drajan (EasoN)   2022-11-08 23:01:00
沒切介面就趕快 refactor 沒測試的軟體能跑嗎
作者: sniper2824 (月夜)   2022-11-08 23:51:00
1
作者: viper9709 (阿達)   2022-11-08 23:57:00
推二樓
作者: Lipraxde (Lipraxde)   2022-11-09 00:00:00
沒出問題的 legacy code 就別想著幫別人加 UT 了,頂多做做整合測試,別把自己搞到懷疑人生
作者: lovdkkkk (dk)   2022-11-09 00:17:00
不確定目前程式的情況, 假如目前程式很亂, 有可能需要先做 2 快速加個整合測試, 重構一下, 之後再做 1
作者: leo08210917 (leo)   2022-11-09 01:07:00
介面切好 弄懂IoC、DI做mock很快 UT也方便舊的可以用防腐層切開 弄整合測試就好
作者: prag222 (prag)   2022-11-09 02:21:00
雖我單元測試沒啥經驗,但說真的就是程式太鳥才依賴性太高,相信用物件導向或設計模式都可以切乾淨的
作者: Lipraxde (Lipraxde)   2022-11-09 07:22:00
只會更糟吧XDDD
作者: bnd0327 (阿噗噗)   2022-11-09 08:53:00
如果BCD沒有被其他函式使用,直接用真的BCD測也無妨
作者: wulouise (在線上!=在電腦前)   2022-11-09 12:10:00
2不算UT,但是你在refactor前可能會寫出2那樣的情況最好先用test framework測整合測試再來refactor
作者: andy831020 (Liszt1020)   2022-11-09 15:23:00
絕對是1 最小單元去測試
作者: lestibournes (Hello World)   2022-11-09 18:28:00
最近也在工作上嘗試導入,覺得應該是1。但光mock就一堆東西,還要擔心測試把程式碼綁死(因為mock/fake的部分已經明確宣告在測試內),還是先硬著頭皮先寫了QQ
作者: CoNsTaR ((const *))   2022-11-09 22:33:00
切 dependency 用 mock,有測試環境的問題用 fake
作者: acgotaku (otaku)   2022-11-10 01:36:00
請善用DI,然後再寫的時候儘量將ABC低耦合 確保你分開測ABC的時候不需要在mock,做假資料的時候儘量是真實狀況
作者: s8952889 (s8952889)   2022-11-10 12:51:00
當然是1吧,如果你今天改B的程式碼結果A的單元測試錯了很奇怪不過其實在單元測試的檔案寫整合測試也是沒問題的吧

Links booklink

Contact Us: admin [ a t ] ucptt.com