將單元測試實作於專案時，發現絕大部分API都是針對資料庫做CRUD，這部分程式透過in
memory 寫了整合測試，越寫越覺得不對勁，心想單元測試數量不是應該要最多？ 網路文
章、影片或實體書籍大多也在探討如何寫單元測試，整合測試資源相對少，在想是不是我
哪裡做錯了，懇請各位大神指教。

以傳統三層式架構來說我多半是測中間的商業邏輯層

看情況，只要整合測試寫/改起來不累，單元測試就沒那麼重要數量差距不用太在意，只要好寫又有效，多一點無妨

實務上，單元測試不是看數量多少，是看覆蓋率。整合測試不是工程師在開發環境寫單元測試，而是在測試環境，QA寫。簡單說，從來不追求數量。追求覆蓋。

小公司不會有賠錢部門QA的

不用在意數量多寡 測試數量會根據你做的架構或軟體類型變化是很正常的一件事 像你說你API都CRUD 那當然單元測試就都通常在測處理資料的商業邏輯 但要是那些邏輯也沒啥好測就甭測了 因為本來就沒啥好測 但如果你是做個圖像引擎之類的東西 單元測試就會變得比較多 因為運算也比較多 合理吧

當然是直接整合測試就好 專案失控才要整天搞單元測試而且ide可以單步除錯 真的要測也不用annotation的爛方式一勞永逸讓專案可控才是最佳品質保證

你寫db/cache用DI寫 可以很方便的 mock 這些依賴但是也有不少做法是在測試時 用你的 db entity 真實建一個db 在緩存中, 這樣測試有一個優點 就是確保你entity是正確的,也可以符合你實際連線的狀況 缺點就是麻煩

CRUD是很制式化的技術應用 想方設法使程式碼簡潔且邏輯圓融 做到這一步即便你不寫測試多半應用不會有錯見到更多的是程式碼亂七八糟寫測試想hold住質量的...當然已經是屎山的就冏了別人的產品可以不必搞到這樣 但有某種程度方便很多