支援TestContainer資料庫整合自動化測試的Clean Architecture專案模版-2024年版總結
在前幾份工作透過課程學過單元測試與重構，工作領域就是較多的傳統三層式架構(ex: Presentation-Service-Repository)，直到前一份接觸到了實務的Clean Architecture方案開始(約莫三年)，發現了C#開發的新天地，終於有一種先前課程單元測試與重構、極速開發學到的技巧有機會應用到工作上的感覺。
因此最近在多個產品領域逐步試驗抽換，有些產品是從0-1，我覺得相對容易，只要開發Pattern形成，其實風格跟文化就會自動形成。
大概的要素如下:
- Clean Architecture的專案模版(EFCore .NET+ MediatR-CQRS)
- 自動化 IntegrationTest + UnitTest
Clean Architecture的專案模板(EFCore .NET+ MediatR-CQRS)
傳統 N 層架構與 Clean Architecture 的差異
最大的不同在於 依賴注入（DI） 的引入後，Infrastructure 層 會 參考 Application 層，而 API 層 則參考 Application 層 的 MediatR 物件。MediatR 提供了一種 標準化的行為，讓使用層（Client 或 API）可以透過抽象方法進行呼叫（類似 Invoke Action）。透過 IRequest + IRequestHandler，請求會標準化地傳遞至 Application 層 執行。這樣的設計提高了 可測試性，因為大部分的 業務邏輯內聚在 Application 層，不像傳統架構可能將部分邏輯散落在 Web API 等層級中。當然，開發者仍然可以 不遵循原則，把邏輯寫得分散，這就需要有意識地去避免這種情況。在這樣的架構下，Web API 的 Controller 只需專注於與 IHttpContext 交互，或處理 Request-Level 事務，例如： Mapping Command / Query 物件
到了 Application 層，應該只剩下 業務邏輯，不應與 HttpContext 這類原生或底層物件耦合。這樣能大幅提高 Application 層的可測試性。反之Infrastructure 層 應該完全封裝對外部系統（如 Redis、資料庫（DB）、其他第三方套件）的實作，外部專案只能透過 Interface 操作，確保解耦與可維護性。
在 Clean Architecture 中，DbContext 屬於 Infrastructure 層，而 Entities 則歸屬 Domain 層。實際上，Entity 本質上就是資料庫表的物件對應。如果 Schema 設計符合 Use Case，資料操作起來就會 更直覺，就像在處理業務邏輯，而不只是冷冰冰的 SQL 操作（如 Insert、Update、Delete）。
使用了EntityFramework後，雖然我們可以透過 DI 綁定 IDBContext，讓任意使用端操作資料庫。這樣的做法 雖然方便，但不建議長期使用。或許在 開發初期，這種方式有助於 自動化測試，因為 TDD 產生的測試可以直接驗證資料庫行為。然而，當系統進入 重構階段，應將 IDBContext 介面 從 Application 層 提取到 Service 層，這樣的調整 將會非常輕鬆，同時也能讓架構更符合 Clean Architecture 原則。
自動化 IntegrationTest + UnitTest
單元測試的 3A 原則（Arrange, Act, Assert），以及 Mock、Fake、Stub 等技巧固然重要，但這裡想強調的是一個 觀念上的轉變。我認為 單元測試不僅僅是函式層級的測試，而是 只要測試對象可以完全控制，就能算是單元測試。如果一個函式綁定了資料庫操作，是否還能進行單元測試？我認為可以。只要能在測試前準備好資料庫，並在測試結束時清除資料，那麼就能夠 更真實地模擬函式的行為。
這樣的做法避免了繁瑣的 Mock 設定，因此 TestContainer 應運而生。過去，準備一個測試用資料庫相對麻煩，不僅需要在本機安裝，還要在 CI/CD 環境中對應不同的資料庫實例。但隨著 Docker 的出現，以及 微軟支援 Docker 版 SQL Server，這個問題得到了有效解決。因此，因為「資料庫」難以”測試”已不應再成為藉口。
曾有人問我，許多業務邏輯因為過度依賴資料庫，而導致難以進行良好的單元測試。常見的解法是 將資料庫操作封裝進 IRepository，但接下來的問題是：我們是否應該對 IRepository 進行 Mock？我的結論是：看需求與團隊接受程度。如果我們可以 自動建置資料庫，且 IRepository 主要對接資料庫，那麼就應該讓測試驗證實際的資料庫操作。如果不測試，我認為測試是不完整的，這樣的測試結果也不太令人安心。至於 IProxy 介接外部 API 的部分，我認為這屬於 異質系統，通常交由外部團隊維護，因此建議 Mock 掉。
TestContainer 與 Integration Test
在了解 TestContainer 的概念後，我們的目標是讓 每次測試（包含 CI Pipeline）都能進行 Integration Test。因此，我建議採取以下做法：
1. 透過 Docker 自動建立資料庫
2. 自動建置 Schema（可參考 Repository 中 IntegrationTest 的 BeforeRun）
3. 自動升級資料庫版本，確保 Application 依賴的資料庫狀態正確
如此一來，撰寫每個 Test Case 時，數據層都能確保已被測試。
最後，我建議搭配 Database.Reset 套件（目前支援 SQL Server 與 PostgreSQL），以便快速重置資料庫，確保每次測試環境的一致性。這樣一來，我們就能實踐 「整合單元測試」（Integration Unit Test）。
維護成本與 Schema 同步
維護成本主要來自於 Schema 的同步，這部分可由 DBA 維護，或 團隊自行定義同步方式。這裡沒有標準做法，重點是讓流程 舒適、易於維護，才能長期執行下去。
這些做法在我們團隊已經試驗超過半年，整體來說 可行，團隊成員也已經習慣撰寫測試，並且包含 數據庫驗證測試。目前，我正協助 其他產品團隊 導入 自動化數據庫測試流，調整適合他們的方案。
當然，這個過程難以避免 一定程度的重構，而且不同方案各有風險。由於大多數系統缺乏良好的測試保護，導致改造充滿挑戰。然而，透過 測試技巧，可以逐步 抽離 Interface（這是我認為最重要的一步）。
整體來看，主要的挑戰在於 改造策略與推進進度，但這 並非技術或測試不可行的問題。這部分有機會的話，我會在後續進一步分享。
Clean Architecture 的一般化方案
為了讓 微軟 C# Application 能夠 快速理解並導入 Clean Architecture，我對這套架構進行了一定程度的 一般化整理，並已經在 GitHub 上建立範本。這不僅是個紀錄，也能作為 範本，方便有需要的團隊 直接導入或參考。
連結如下: https://github.com/pin0513/ECAppForCleanArchitecture
todo: 會持續將 MediatR的案例整合進去哦