Re: [討論] Unit test 的撰寫請益

看板Soft_Job作者 (關鍵字)時間1年前 (2022/11/09 07:07), 1年前編輯推噓11(1109)
留言20則, 10人參與, 1年前最新討論串2/4 (看更多)
大家都選1嗎?我覺得二比較好 Google的guideline是Prefer Realism Over Isolation 詳見 https://abseil.io/resources/swe-book/html/ch13.html TotT有關fakes的討論也提到 Fakes are useful for when you can't use the real implementation in a test https://testing.googleblog.com/2013/06/testing-on-toilet-fake-your-way-to.html 總之能用real implementation的時候就不要用fake ※ 引述《shane87123 (陽光大肥宅)》之銘言: : 先說我對 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), 來自: 75.172.24.41 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1667948850.A.92B.html

11/09 08:49, 1年前 , 1F
端看單元如何定義,如果有些類別或函式只是為了服務特定
11/09 08:49, 1F

11/09 08:50, 1年前 , 2F
類別或函式,那本質上相當於私有,就可以不用特地mock
11/09 08:50, 2F

11/09 09:42, 1年前 , 3F
它主要的考量是維護成本,fake 一樣是需要維護的
11/09 09:42, 3F

11/09 09:55, 1年前 , 4F

11/09 09:55, 1年前 , 5F
這篇也有相關討論,供大家參考
11/09 09:55, 5F

11/09 10:10, 1年前 , 6F
有可能估狗的員工素質與程式品質搭上測試適合那句估狗的
11/09 10:10, 6F

11/09 10:10, 1年前 , 7F
guideline, 其它公司未必適用
11/09 10:10, 7F
確實,其他公司大概沒有Google的monorepo還有CI infra? ※ 編輯: Keyword (75.172.24.41 美國), 11/09/2022 11:10:30

11/09 12:26, 1年前 , 8F
如果 e2e 測出問題後能被快速定位就適合,而能快速定位
11/09 12:26, 8F

11/09 12:27, 1年前 , 9F
有很多可能,可能是工程師很會找問題,或錯誤訊息很清楚
11/09 12:27, 9F

11/09 12:28, 1年前 , 10F
或者有很完善的 log 追踪規劃等等
11/09 12:28, 10F

11/09 12:30, 1年前 , 11F
亦即這個 guideline 有效 多半也是搭配其它多個面向的條
11/09 12:30, 11F

11/09 12:30, 1年前 , 12F
件或其它 guideline,整體湊齊之後有效
11/09 12:30, 12F

11/09 13:40, 1年前 , 13F
如果都用介面方式用1,再用套件模擬這樣就最單純其他多的
11/09 13:40, 13F

11/09 13:40, 1年前 , 14F
再做
11/09 13:40, 14F

11/09 18:40, 1年前 , 15F
fake 太多跟本反應不出真實情況
11/09 18:40, 15F

11/09 19:24, 1年前 , 16F
Unit test不需要考慮真實情況,而是該單元的實作有沒有
11/09 19:24, 16F

11/09 19:24, 1年前 , 17F
問題。
11/09 19:24, 17F

11/09 23:49, 1年前 , 18F
反應真實情況 那不就相同code跑ut結果可能不一樣
11/09 23:49, 18F

11/10 06:57, 1年前 , 19F
用整合測試 integration test來測
11/10 06:57, 19F

11/10 12:41, 1年前 , 20F
Unit test 配合後續的e2e
11/10 12:41, 20F
文章代碼(AID): #1ZQk4oah (Soft_Job)
文章代碼(AID): #1ZQk4oah (Soft_Job)