為什麼這篇單元測試 範圍鄉民發文收入到精華區：因為在單元測試 範圍這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者lovdkkkk (dk)看板Soft_Job標題Re: [請益] 如何實現單元測試多於整合測試...
單元測試 範圍 在 大考超詳解 KOL (C.C. Workshop) Instagram 的最佳貼文
2021-09-16 09:24:51
🔍 超詳解 🔍 主題：學測考前大補帖（領取時間已於9/19截止） 🔍 補帖範圍 超詳解前次舉辦的「化學考前大補帖」獲得熱烈支持與好評...於是我們決定要推出「數學Ｘ英文Ｘ自然三科大補帖」啦！ - 題源取自111學測第二次試辦考試，剛出爐的最新考題佐超詳解團隊最詳盡、家教式的解說，讓你能夠搞清楚...
先確認一下，不知道你們是不是用一些潮潮 der 框架，
然後那框架的官方文件給的範例是看起來簡潔漂亮清楚的一兩行 code，
(例如 service 裡一個查詢 > return 結果)
然後你們把範例 copy 過來改，直接往裡面塞邏輯？
如果是這樣，可能需要先做的是把 CRUD 分割出去，
把所有 "用某些參數組一些查詢取得查詢結果" 這樣的東西包出去變成方法呼叫。
這樣做之後，應該就能很容易的 mock 掉 CRUD 的部份
然後我覺得更好的情況會是把商業邏輯也包出去，
這樣就可以從 service 層再切出更核心更通用的 core 部份，
core 的部份不依賴於任何框架或外部環境，
只包含 "接收資料處理邏輯回傳資料"
這樣做之後，應該就能很單純的直接給資料測 core 的部份，無需任何 mock
(或者說 mock 就是 testing data 本身)
然後哪一種測試要多是依你們的需要而定，
通常整合測試可以 "花較少的時間力氣測較大的範圍"，
如果需要的是做上 production 之前的防護網會比較適合
單元測試足夠則可以 "較明確的指出目前有問題與確定正常的部份"
如果需要的是遇到問題時能快速的排查與修復就多加一些
※ 引述《a804372004 (忽冷忽熱摸不著)》之銘言：
: 將單元測試實作於專案時，發現絕大部分API都是針對資料庫做CRUD，這部分程式透過in
: memory 寫了整合測試，越寫越覺得不對勁，心想單元測試數量不是應該要最多？ 網路文
: 章、影片或實體書籍大多也在探討如何寫單元測試，整合測試資源相對少，在想是不是我
: 哪裡做錯了，懇請各位大神指教。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.226.175.248 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1668932484.A.DB0.html
推 a804372004: 在Service層透過Repository對資料庫做CRUD，商業邏輯 11/23 16:04
→ a804372004: 的部份較少，也許單元測試的需求就沒這麼多？ 11/23 16:07
那的確是，假如都是單純的 API 讀資料庫回傳結果這類操作，
基本上也沒什麼東西能拿去做單元測試
單元測試我覺得有幾類比較需要 :
1. 底層核心，偏 utils 的，例如 距離計算，日期的格式化或 parse 等
它們可能被廣泛的用在許多地方，比較不能出錯
2. 本身內部邏輯複雜的，例如依多項參數計算費用或生成合約
它們如果出錯 debug 難度會較高，
有單元測試可協助快速縮小可能出問題的範圍
3. 被用在很多步驟的一組流程中的，例如要打多個 API 的一組流程，
如共享交通的借還車，這類型的當有問題但整合測試測不出來時
(例如打 API 的順序不對，整合測試也沒測該順序的 case)
若有單元測試則可快速確認是不是底層實作的問題，
如果確認不是就能很快的調整排查的方向
→ peter9s3b: 越oo越容易寫unittest，先寫unittest，元件抽象比較高 11/29 07:00
不那麼直接
有 "好的邊界與流程" 會好測試，而 OO 是實現的手法之一，
不過不是唯一的方式，也不保證使用 OO 必然能實現 "好的邊界與流程"
※ 編輯: lovdkkkk (111.241.166.152 臺灣), 12/01/2022 12:21:42