在 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 寫整合測試時，碰到一點小問題，以下是解決問題的經過
現在的工作大都是使用微軟內建的 Json 序列化套件 System.Text.Json，為什麼要用可以參考 黑大這一篇，在尋求 Json Compare/Diff 解決方案時大都是看到 Newtonsoft(Json.NET) 的 JsonDiffPatch 做法，經同事分享 System.Text.Json 已經有人實作出來了，知道後立馬套用
一旦 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 使用
前面幾篇使用 ChangeTracking 來幫我們追蹤物件狀態，但他必須公開狀態讓外部可以修改，為了解決不被外部隨意修改的問題，可以利用深複製回傳一份不同實例的物件，這樣就可以不被外部影響；操作資料庫仍是使用 EF / EF Core，當然這不受限，你可以挑選妳喜歡的控制方式，接著，來看看怎麼實現它吧。
上一篇提到了 ChangeTracking + EFCore.BulkExtensions.BatchUpdate，可以很輕易的幫我們產生出有異動的 Update SQL 語法，如何使用 ChangeTracking 追蹤物件變化再透過 EFCore.BulkExtensions 存到資料庫
很可惜的是 EFCore.BulkExtensions.BatchUpdate 沒有支援異動多張資料表，對於資料庫命令的往返會隨著異動的資料表而增加，這次我想要改使用 EF Core 原生的異動追蹤。
追蹤異動變化使用 ChangeTracking ，消化異動並存放到操作資料庫則使用 EF / EF Core，當然，這不受限，你可以挑選妳喜歡的控制方式，接著，來看看怎麼實現它吧。
以往我都使用 dotTrace 診斷 .NET 應用程式的使用狀況，可以得知執行時間、佔用記憶體、SQL Command 等。
但，NET Core 沒有支援 SQL ETW，代表攔截不到有關 SQL 的命令，於是我得尋求其它解方，MiniProfiler 則是這次的調查對象。
當有一個應用程序被用戶 ( SIGINT /Ctrl+C) 或 Docker ( SIGTERM / docker stop ) 停止時，它需要優雅地關閉一個長時間運行的工作；換句煥說，當應用程式收到關閉訊號的時候，要把工作做完，應用程式才可以關閉。微軟的 Microsoft.Extensions.Hosting 可以幫我們接收/處理關閉訊號，我們只需要告訴它要怎麼做就可以了，我在實作的過程當中，碰到了一些問題，以下是我的心得
以往 ASP.NET Core 可以使用 TestServer 來進行整合測試，現在多了一個選擇 WebApplicationFactory，WebApplicationFactory 基於 TestServer 又封裝了更多的功能，我覺得使用起來又更簡單了，如果可以的話可以改用它