先確認一下，不知道你們是不是用一些潮潮 der 框架， 然後那框架的官方文件給的範例是看起來簡潔漂亮清楚的一兩行 code， (例如 service 裡一個查詢 > return 結果) 然後你們把範例 copy 過來改，直接往裡面塞邏輯？ 如果是這樣，可能需要先做的是把 CRUD 分割出去， 把所有 "用某些參數組一些查詢取得查詢結果" 這樣的東西包出去變成方法呼叫。 這樣做之後，應該就能很容易的 mock 掉 CRUD 的部份 然後我覺得更好的情況會是把商業邏輯也包出去， 這樣就可以從 service 層再切出更核心更通用的 core 部份， core 的部份不依賴於任何框架或外部環境， 只包含 "接收資料處理邏輯回傳資料" 這樣做之後，應該就能很單純的直接給資料測 core 的部份，無需任何 mock (或者說 mock 就是 testing data 本身) 然後哪一種測試要多是依你們的需要而定， 通常整合測試可以 "花較少的時間力氣測較大的範圍"， 如果需要的是做上 production 之前的防護網會比較適合 單元測試足夠則可以 "較明確的指出目前有問題與確定正常的部份" 如果需要的是遇到問題時能快速的排查與修復就多加一些 ※ 引述《a804372004 (忽冷忽熱摸不著)》之銘言： : 將單元測試實作於專案時，發現絕大部分API都是針對資料庫做CRUD，這部分程式透過in : memory 寫了整合測試，越寫越覺得不對勁，心想單元測試數量不是應該要最多？ 網路文 : 章、影片或實體書籍大多也在探討如何寫單元測試，整合測試資源相對少，在想是不是我 : 哪裡做錯了，懇請各位大神指教。 -- ※ 發信站: 批踢踢實業坊(pttsite.org.tw), 來自: 36.226.175.248 (臺灣) ※ 文章網址: https://pttsite.org.tw/Soft_Job/M.1668932484.A.DB0