大家好，目前在開發一個 .NET C# 專案，主要功能大多都是在做資料庫的 CRUD（讀寫資料、更新狀態、查詢列表等等），商業邏輯相對比較薄。

我在規劃自動化測試時遇到一個情況：
如果只照「不碰外部依賴」的標準來切單元測試（unit test），可以寫的內容其實非常有限，因為多數方法都會連到資料庫。

就會變成：單元測試能覆蓋的比例很少，而實際風險比較大的部分（資料庫互動、CRUD 正不正常）反而都沒被測到。

所以想請教大家幾個問題：

問題一：遇到這種「以資料庫 CRUD 為主」的 .NET 專案時，實務上會怎麼做？

是乾脆直接以整合測試（integration test）為主，讓測試真的打「測試用資料庫」去驗證 CRUD？

還是會把方法內容做分類：

1. 和資料庫無關的邏輯（參數檢查、計算、格式轉換…）放在「單元測試專案」，完全不打 DB，只測純邏輯；
2. 真的要連資料庫、檔案等外部依賴的部分，用「整合測試專案」來測，讓它打實際的測試 DB 或 Docker DB？

問題二：一般企業在真正對客戶的專案上，會不會也這樣做？

例如：

solution 裡真的分 XXX.Tests.Unit / XXX.Tests.Integration 兩個測試專案；

CI/CD 裡 PR 只跑 unit tests，整合測試改成 nightly build 或特定 branch 才跑。

還是實務上很多團隊會：

主要靠整合測試去打實際 DB，確保 CRUD 正常；

單元測試只補少量關鍵的純邏輯？

問題三：如果前面兩點的方向是合理的話，那整合測試是不是也可以直接用「單元測試框架」來寫？

我的預期是：一樣用 xUnit 當測試框架，但是這個 test 專案定位是「整合測試」，不是單元測試。

測試內容會真的連到 MySQL 測試資料庫，去跑整套 CRUD：新增、查詢、更新、刪除。

有查到一些資料顯示：

ASP.NET Core 官方文件本身就是用 xUnit 來示範整合測試（配合 WebApplicationFactory 等）。

也有不少文章是用 xUnit 搭配實際資料庫（或 Docker 起來的 DB）做整合測試，包含 CRUD 場景。

想確認一下大家的看法：

在實務上，用 xUnit 這種「原本叫單元測試框架」的東西來寫整合測試，是不是很常見、也算正常做法？

還是你們會刻意用不同框架 / 不同專案型別做區隔？

環境補充：

• 開發工具：Visual Studio 2022
• 資料庫：MySQL
• 預計測試框架：xUnit（希望同時負責 Unit + Integration，不同專案或不同分類）

目前自己的直覺做法是：

建一個「Unit Tests 專案」：只測不依賴 DB 的邏輯，外部依賴一律用介面 + mock/fake。
再建一個「Integration Tests 專案」：
用 xUnit + 測試 MySQL（或 Docker MySQL），寫幾條關鍵 CRUD 流程，把資料新增 → 讀出 → 更新 → 刪除的整個流程跑過。

但因為這是要用在「真的給客戶用的專案」，所以比較想知道大家在實際商用 / 客戶案子裡，是不是也會這樣做？
你們會怎麼拿捏 unit vs integration 的比例？
有沒有實際踩過的坑或建議的專案結構？

非常感謝願意分享實務經驗的前輩