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

先說在前面

雖然聽起來很幹話，但很多東西沒有標準答案
有時是合適度的問題，也可能是喜好（品味？）的問題

同一個題目，實際的 code 長得不一樣，可能也會用不同的方法處理


另外，除了資源豐富到人力充沛到不行的專案，以及幾乎沒有時程壓力
的專案（很多開源專案屬於後者），少有專案能把測試能做到真正完整

很多時候是取捨，花時間寫多少測試，能 cover 到最大的範圍
剩下的部分靠整合測試（包含自動與手動）來抓

經驗能讓人能更快做出效益更好的取捨

在「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，選哪邊？


我的回答是：
這兩個都是選項，但不是只有這兩個選項。
例如重構，例如在其他地方準備抽象資料層，也都是選擇。
甚至手上的專案也可能變出不同的把戲。

這些都是能打的牌，要看場上環境怎樣，再來取捨該打哪幾張。



--
莉～娜～在～我～們～之～間～有～名~嗎～？

打倒了魔王大人，被那位大人附體之後平安無事地打倒了冥王大人
擊退了霸王大人，然後又打倒了魔王大人。

這種傢伙還不有名？魔族有那麼粗神經嗎？有那麼沒危機意識嗎？

--