這是 Visual Studio 裡的一個延伸模組 (Extension)，大約在四五年前在 Visual Stuidio 2019 時就已經發佈的一個工具，而我在過去帶新人教單元測試時都會介紹這個工具，透過這個工具取得測試的程式碼覆蓋範圍。
因為我平常的開發工具是使用 JetBrains Rider，已經有內建 Code Coverage 的功能，我只有在做教學或寫文件、找問題、重現別人問題情境的時候才會開啟 VS2022，在三月底四月初時這個工具產生 Code Coverage 的功能都還正常，但是卻在前幾天因為在整理文件時久違地開啟 Visual Studio 2022 並且要取得 Code Coverage 卻出現了異常，在找尋問題原因以及嘗試如何解決花了不少的時間，最後是順利地找到原因並且排除了狀況。於是就寫了這篇文章來介紹工具並說明要怎麼解決異常狀況。
在開發系統時，如果測試情境的輸出會有許多資料類別並且要驗證很多欄位時，會利用 object graph 比對整個結果是否和預期一致。
現在我的專案裡有個 CustomerRootData 類別，裡頭屬性為十幾個不同型別的子集合，每個類別都有 UpdateTime、UpdateUser 這兩個欄位，但這兩個欄位是在程式執行當下才寫進去的，不屬於測試驗證的重點，在寫測試的時候常常陷入重複設定的地獄。
於是在 AwesomeAssertions / AwesomeAssertions Object Graphs 的架構下，想辦法在做比對時去做到比較方便省事的設定方法，讓我輕鬆地去排除指定的欄位。
在找尋資料、解決方法的同時，也讓我得知不一樣的處理方式，將這些處理方式用文章記錄下來，也提供給大家做個參考。
其實這也不是新聞了，早在今年 1/15 時大家就已經知道並且被商業授權的費用給嚇了一大跳（每個人 $129.95 USD）。
現在特地寫一篇是因為上週因為 AutoMapper 將要變成商業化授權而寫了兩篇文章介紹替代套件，就想到好像並沒有對於 Fluent Assertions 轉變為商業授權去寫一篇文章與替代方案，於是就以 Fluent Assertions 從 v8.0.0 起轉為商業授權，簡單寫了這篇去說明授權限制、專案應對策略，以及替代的 Assertion Library，提供給大家做個參考。
前面分享的兩篇文章，分別介紹了 Microsoft.Bcl.TimeProvider 和 AutoFixture 的 AutoData
另外在寫測試時，可以使用 FakeTimeProvider 去做抽換，就可以設定時區、時間來完成測試情境的執行。
那麼是不是也可以用 AutoData 的特性，讓我們在寫測試的時候可以省下建立 FakeTimeProvider 的步驟呢？當然可以，不過需要先瞭解該怎麼做、可以怎麼做以及應該如何做。
這是一篇借花獻佛、拾人牙慧的文章，之前有寫過這麼一篇文章「單元測試使用 AutoFixture.AutoNSubstitute」
當時是使用了 AutoFixture.AutoNSubsititute 來減少測試類別裡相依類別的 Stub 建立步驟，用了很奇怪的方式來解決我當時的煩惱。
直到我進入到另一個團隊後，才知道可以藉由 AutoFixture.AutoData 做到更為簡單與彈性的解決方式，這篇就來簡單介紹怎麼做。
我想很多人看到標題後都會直接想
「程式裡直接用 DateTime 難道錯了嗎？」
「DateTime 用得好好的，為什麼要改用 Microsoft.Bcl.TimeProvider ?」
「我又不必寫測試，我就是要用 DateTime！」
我也管不著各位想怎麼用、想怎麼寫程式，只是看到很多有關於交易處理的程式都是跟時間判斷有關，而且有著種種原因而沒有寫測試，就讓人覺得那些產品妥當嗎？
而且一遇到 DateTime 的處理，就會卡在不知道如何寫測試。
所以就來寫這一篇簡單介紹 Microsoft.Bcl.TimeProvider
在去年 10 月寫了這一篇文「Repository 測試使用 Testcontainers」，不過文章裡只有公開部分的程式碼類別，可能會讓有些人想跟著實做卻會遇到做不出來的狀況。
但因為實際的程式原始碼已經不在了，所以我就重做了一個新的專案，盡量還原當時的範例專案，之前文章裡的測試專案是使用 MSTest，而這個新建立的專案則是提供了 xUnit 與 MSTest 兩種測試專案，讓使用這兩種測試框架的開發人員可以參考。
其實這也不一定是在整合測試才會用到，一般會呼叫使用到外部 API 時的情境也一樣適用。
當要將一個物件的資料帶入 QueryString 時，每次就會覺得這個步驟很麻煩，甚至有一段時間是自己寫個方法來處理，但總覺得不是一個漂亮的解決方式，
於是就想到可以使用 Flurl 來處理，也的確是可以簡化以前那些繁瑣的建立 QueryString 的作法。
前一篇「xUnit 完全使用 FluentDocker 建立 MongoDB 的 Docker Image 和 Docker Container」裡用了兩個步驟分別建立 docker-image 和 docker-container，而建立 docker-image 是透過執行 docker-compose.yml 的方式。
如果不想要這麼麻煩地分成兩步驟，而是想要執行一次 docker-compose 就完成 docker-image 和 docker-container 的建立，這篇文章就來簡單說明如何進行。
前一篇文章「建立測試用 Container 前先建立 Docker Image - 使用 FluentDocker」是在 xUint 測試專案裡使用了 FluentDocker 和 Testcontainers 分別建立 Docker Image 與 Docker Container，這一篇就單純地展示完全使用 FluentDocker 來完成 Docker Image 和 Docker Container 的建立。