[討論] Unit test 的撰寫請益
先說我對 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
--
你可以先讀重構相關的書
如果模組化有做好,那你1.做得是正確的事情。正常來
說就是Function跟Process分開測,最後再來個整合測試
。然後不要抗拒為各別Function寫Unittest
我本來預期就是為個別檔案的個別function寫unit test,不過不確定這樣做是不是有符合u nit test的特性
單元測試的話1
用1吧,如果要測試的function長文章那樣,那本來就應該
花時間寫BCD的test case
謝謝各位大大,那我可以放心去fake了
不知道你用什麼語言,通常會有tool幫你攔截dep的function
然後去呼叫對應的fake function
應是用google test,沒錯,他可以去呼叫fake function。這部分的實作應該沒什麼問題
對了 不寫這個測試會怎樣?
合起來測也是種測法,只是那就不是unit test了
專案如果沒有在切介面,直接硬fake會寫到懷疑人生
gmock 就是1啊
gmock gtest框架都有了,你想得到的問題大公司都想到了
,直接整套拿去用就好
沒切介面就趕快 refactor 沒測試的軟體能跑嗎
1
推二樓
沒出問題的 legacy code 就別想著幫別人加 UT 了,頂多
做做整合測試,別把自己搞到懷疑人生
不確定目前程式的情況, 假如目前程式很亂, 有可能需要先
做 2 快速加個整合測試, 重構一下, 之後再做 1
介面切好 弄懂IoC、DI做mock很快 UT也方便
舊的可以用防腐層切開 弄整合測試就好
雖我單元測試沒啥經驗,但說真的就是程式太鳥才依賴性
太高,相信用物件導向或設計模式都可以切乾淨的
只會更糟吧XDDD
如果BCD沒有被其他函式使用,直接用真的BCD測也無妨
2不算UT,但是你在refactor前可能會寫出2那樣的情況
最好先用test framework測整合測試再來refactor
絕對是1 最小單元去測試
最近也在工作上嘗試導入,覺得應該是1。但光mock就
一堆東西,還要擔心測試把程式碼綁死(因為mock/fa
ke的部分已經明確宣告在測試內),還是先硬著頭皮
先寫了QQ
切 dependency 用 mock,有測試環境的問題用 fake
請善用DI,然後再寫的時候儘量將ABC低耦合 確保你分開測
ABC的時候不需要在mock,做假資料的時候儘量是真實狀況
當然是1吧,如果你今天改B的程式碼結果A的單元測試錯了
很奇怪
不過其實在單元測試的檔案寫整合測試也是沒問題的吧
33
先說結論,先都不要寫。 Legacy system 要先補大範圍的 integration test,確定整體的行為是對的。 如果 code 沒有要再改,不用補細部 unit tests。 原因是因為,原本 API 可能因為設計不良,導致無法寫 unit test 得先 refactor 才有辦法讓它變成 testable,這情況就要先 refactor 再補 UT13
先說在前面 雖然聽起來很幹話,但很多東西沒有標準答案 有時是合適度的問題,也可能是喜好(品味?)的問題 同一個題目,實際的 code 長得不一樣,可能也會用不同的方法處理 另外,除了資源豐富到人力充沛到不行的專案,以及幾乎沒有時程壓力11
大家都選1嗎?我覺得二比較好 Google的guideline是Prefer Realism Over Isolation 詳見 TotT有關fakes的討論也提到
67
Re: [請益] 接手外包商的code沒交接也沒人可以問我的第一份跟第二份工作都是這個樣子,一開始你會像麻痺的人,給你幾個建議 1. 掌握啟動前的入口 - 大部分程式語言都會有一個從作業系統下命令開始執行 的進入點,可能會載入 config、環境變數、命令參數這些東西,你要先清楚 這些東西的配置意義是什麼。 2. 掌握啟動後的入口 - 如果是 server 或常駐程式,在執行階段就會有監聽行為。23
Re: [討論] 怎樣算是一個合格的junior cpp programme針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖!重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題,TDD 不只要測試,還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序,是否一定要 TDD 這有爭議 08/23 21:3421
Re: [討論] 重構跟kpi的考量如果 A, B 都沒有任何 tests,建議不要動他。 幫 C 實做這個功能的時候,把 unit test 寫好寫滿,確保 C 是對的 行有餘力,針對 A, B 的使用情境也加上 test case,確保未來在 A, B 確實能重用 (這點很重要,否則很容易程式長得很像你以為可以重用,實際上根本不能) 就先做到這樣就好,確保 C 的品質,同時你獲得了高品質的 reusable 模組14
Re: [討論] 有人會換薪水較低但未來性好的工作嗎我原本在某大公司modem team 做SD之類的工作 沒多久就離職去台北一家小公司做廉價智慧手環 年薪才140萬 做一年半被資遣,被資遣的時候什麼都不會只會寫一些C for if else,和老本行碩班念的通信與信號處理。 剛好那陣子流行轉純軟,就刷了七十多題後去面試。運氣好被一家二三線歐洲純軟外商撈起來。14
[討論] OS的程式碼要怎麼trace比較有效率?大家好,小弟的工作跟 MCU 有關 近期工作剛 on board,導師要我先看一個資料夾內的 Code 裡面看起來像是一個 task 的 create、initilize 跟 API 以往經驗,我會先找一個程式的 main function 當入口,然後順著邏輯去看 code 但這套似乎沒辦法用在 Kernel 上,13
Re: [討論] 重構跟kpi的考量感覺這個標題就是個假議題,你說不重構A、B因為Unit test來不及寫,那你新寫的C就不 用unit test了? 然後你又說三個code一模一樣,假設你幫C寫完unit test了,那你不就也把AB搞好了嗎? 再退一萬步來講,AB沒有unit test大家用的那麼爽你還硬要去動也只是吃飽太閒,不如 好好寫你C的unit test,寫完大家就用C就好啦10
[請益] 關於美國 hiring 所需的 drug test不確定這版是否適合請教這個到美國公司工作前的問題。 若這個對美國的科技業不適用的話,請見諒。 最近應該會拿到美國某大型(大概也是世界十大上下)Biopharma 的Research 部門的offer。 對方需要我在收到 the chain of custody form 三天內繳交drug test ,但我目前人X
[問卦] test網路測試是這樣的啦 現在line都有好友生日通知 沒道理不知道誰生日吧? 現在過快一小時了 還沒收到任何訊息X
[問卦] 學妹不寫unit test要怎麼辦?如題 明明說好一人負責一部分 結果她寫完 居然沒有寫unit test !! 這是在戲弄肥宅嗎?