在 ASP.NET Core 的整合測試我們可以使用 WebApplicationFactory、TestServer，這我前面幾篇已經提過了需要的可以參考之前的文章 WebApplicationFactory、TestServer。Middleware 用上述的步驟肯定是沒有問題的，但是需要的環境、步驟也比較多，可能還會因為其他 Middleware 順序所帶來的影響，今天我還要分享 ASP.NET Core內建 Mock HttpContext 做法，讓我們可以快速的針對某一個 Middleware 進行單元測試
C# 9 開始就可以不用在主控台程式包含 main 方法(Top-level statements)，在 .NET 6，ASP.NET Core 6 也支援了 Top-level statements 專案範本，已經直接套用此功能，我用 WebApplicationFactory 寫整合測試時，碰到一點小問題，以下是解決問題的經過
一旦 Web API 部署並開始使用後，它應該是可靠的，並且不應該因任何原因而中斷。另一方面，隨著需求的變化，我們需要更新 Web API 代碼，但這應該不破壞目前 API 的情況下完成，因此新舊版本的 Web API 都將處於活動狀態，功能也要正常。這時候就要靠 Web API 版本控制，我們靠它用於處理不同版本的Web API。微軟的 Microsoft.AspNetCore.Mvc.Versioning 可以讓我們輕易的完成此項目，但我在整合到 Swagger UI / Swashbuckle.AspNetCore 的時候碰到了一些關卡，所幸順利的解決了，以下是我的實作筆記。
前幾年編寫了 [Swagger] 一些 Swagger 編寫文件的技巧和 Client Code Gen ，不過，已經不適用 ASP.NET Core 6，正好，團隊正在重視 API 文件，正好趁這機會更新 Swashbuckle.AspNetCore 使用
以往我都使用 dotTrace 診斷 .NET 應用程式的使用狀況，可以得知執行時間、佔用記憶體、SQL Command 等。
但，NET Core 沒有支援 SQL ETW，代表攔截不到有關 SQL 的命令，於是我得尋求其它解方，MiniProfiler 則是這次的調查對象。
以往 ASP.NET Core 可以使用 TestServer 來進行整合測試，現在多了一個選擇 WebApplicationFactory，WebApplicationFactory 基於 TestServer 又封裝了更多的功能，我覺得使用起來又更簡單了，如果可以的話可以改用它
由於 .NET Core 跨平台，除了可以部署在 VM 的 IIS 之外，Docker 也是選項之一，它的使用體驗甚至比 VM 還要來的好，部署速度也比 VM 快很多
微軟提供的 DI Container (Microsoft.Extensions.DependencyInjection )，實作了 Microsoft.Extensions.DependencyInjection.Abstractions 抽象，讓我們也可很輕易的換成我們習慣的 DI Container，比如說，內建的 Microsoft.Extensions.DependencyInjection 沒有提供掃描 Assembly 的自動註冊，這時，在應用程式的進入點換成其它的 DI Container，比如 Autofac，就可以使用自動註冊。
只有增加使用 Autofac DI Container 的註冊，其餘的不用動，像是物件的依賴關係，取出物件方式。
Microsoft.Extensions.DependencyInjection 是微軟實作的 DI Container，在 ASP.NET Core 大量的使用，無形之間已經成為一種開發標準，過去，還沒有使用 DI Container 時，我會使用靜態屬性來集中管理物件的生命週期，現在，集中管理物件的生命週期，我又多了一個選擇。
Microsoft.Extensions.DependencyInjection 支援 .NET Fx 4.6.1 以上