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

看板Soft_Job作者GALINE (天真可愛CQD)時間1年前 (2022/11/09 14:19)推噓12(12推 0噓 4→)

留言16則, 15人參與討論串3/4 (看更多)

※ 引述《shane87123 (陽光大肥宅)》之銘言：先說在前面雖然聽起來很幹話，但很多東西沒有標準答案有時是合適度的問題，也可能是喜好（品味？）的問題同一個題目，實際的 code 長得不一樣，可能也會用不同的方法處理另外，除了資源豐富到人力充沛到不行的專案，以及幾乎沒有時程壓力的專案（很多開源專案屬於後者），少有專案能把測試能做到真正完整很多時候是取捨，花時間寫多少測試，能 cover 到最大的範圍剩下的部分靠整合測試（包含自動與手動）來抓經驗能讓人能更快做出效益更好的取捨 : 先說我對 Unit test 的看法：測試單元（可能是 function）的邏輯是否正確 : 常常會有一份 code 內其實呼叫了很多別份 code 的 function， : 舉例來說 : A() { : B(); : C(); : if (check) : D(); : } 在「unit test」的前提之下，A() 這個「單元」要怎麼被定義？ - B() C() D() 的集合體？ - 負責分派邏輯前往 B() C() D() 的 router？ - A() 本身就做了一大堆事情，BCD 只是輔助？ - 其他？在不同的狀況下，該測的單元功能會完全不一樣適合的可能做法也完全不同例如說對於狀況1 - 也許該把那個 if 檢查丟進 D()，讓 A() 就只是依序呼叫三個其他人的傳聲筒接著不測 A() 但認真測 B() C() D() - 沒有副作用可以，有副作用的話怎麼驗證副作用？例如說對於狀況2 - 是不是該把 B / C / D 弄成變數傳進 A？ - 沒在寫 C 不知道 C 能怎麼做，function pointer？ - 或是有某種類似 router 定義的東西，然後測 router 功能？例如說對於狀況3 - 全部 fake 是不是比較快？ - 是不是該把這個 function 拆掉？ - 誒，看到七層的 if else，真的覺得拆的掉嗎？ - 誒，看到七層的 if else，真的覺得要伴他一生一世嗎？其實「重構」是個很常該被考慮的選項。但當然，重構有時是個繁重的工作，也不見得是最常被選擇的選項這也是 TDD 曾經風行一時的一部分原因，因為腦袋正常的工程師走 TDD 會避免自己寫出「啊，這要能測會把測試寫的有夠屎」的 code 但走 TDD 也可能寫出「看得懂想測什麼，但邏輯怎麼會這樣切」的東西另外自己經驗是通常測試難寫是跟資料有關「某些時候」如果非常辛苦的把資料 IO 全部 mock 一層，後面會好做一點例如之前看過 api 專案平常線上是戳 MySQL 拿資料在跑測試的時候直接開一個 in memory 的 sqlite 來當後端測試邏輯會先把資料塞好好再來跑測試於是就可以測「拿文章的時候會把內文特定 tag 換成其他 table 的資料」之類資料連結度高的東西走這條路的話不 fake 直接把邏輯跑完也是個好選項了或者不用全部 fake，可以只 fake 幾個這大概不算是「單元」測試吧但該測的有測到，而且在艱苦的工程之後可以輕鬆往上疊一堆其他測試（但..如果沒有那麼多東西要測，這會不會太厚工？）另外不同程式語言（或不同輔助函式庫？）的狀況會天差地北例如上面的 A()，如果是 python 的話可能可以不改 code 直接用 patch() 把 B() C() D() 變成 mocker，會回傳需要的值測試就直接檢查 B/C 是不是每次都被呼叫到 D() 是不是條件對的時候有呼叫到因為 mock 容易寫，全部 fake 掉會變成更有吸引力的選項所以回到原本的題目：全部 fake 跟全部不要 fake，選哪邊？我的回答是：這兩個都是選項，但不是只有這兩個選項。例如重構，例如在其他地方準備抽象資料層，也都是選擇。甚至手上的專案也可能變出不同的把戲。這些都是能打的牌，要看場上環境怎樣，再來取捨該打哪幾張。 -- 莉～娜～在～我～們～之～間～有～名~嗎～？打倒了魔王大人，被那位大人附體之後平安無事地打倒了冥王大人擊退了霸王大人，然後又打倒了魔王大人。這種傢伙還不有名？魔族有那麼粗神經嗎？有那麼沒危機意識嗎？ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 218.166.60.66 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1667974776.A.0BC.html

→

hackfox

11/09 14:50, 1年前 , 1^F

11/09 14:50, 1^F

推

FatFatPig

11/09 16:49, 1年前 , 2^F

11/09 16:49, 2^F

推

t64141

11/09 16:56, 1年前 , 3^F

11/09 16:56, 3^F