在開發系統時，如果測試情境的輸出會有許多資料類別並且要驗證很多欄位時，會利用 object graph 比對整個結果是否和預期一致。
現在我的專案裡有個 CustomerRootData 類別，裡頭屬性為十幾個不同型別的子集合，每個類別都有 UpdateTime、UpdateUser 這兩個欄位，但這兩個欄位是在程式執行當下才寫進去的，不屬於測試驗證的重點，在寫測試的時候常常陷入重複設定的地獄。
於是在 AwesomeAssertions / AwesomeAssertions Object Graphs 的架構下，想辦法在做比對時去做到比較方便省事的設定方法，讓我輕鬆地去排除指定的欄位。
在找尋資料、解決方法的同時，也讓我得知不一樣的處理方式，將這些處理方式用文章記錄下來，也提供給大家做個參考。
其實這也不是新聞了，早在今年 1/15 時大家就已經知道並且被商業授權的費用給嚇了一大跳（每個人 $129.95 USD）。
現在特地寫一篇是因為上週因為 AutoMapper 將要變成商業化授權而寫了兩篇文章介紹替代套件，就想到好像並沒有對於 Fluent Assertions 轉變為商業授權去寫一篇文章與替代方案，於是就以 Fluent Assertions 從 v8.0.0 起轉為商業授權，簡單寫了這篇去說明授權限制、專案應對策略，以及替代的 Assertion Library，提供給大家做個參考。
Mapperly 在以前找尋替代 AutoMapper 的時候就有看過，但當時著重在與 AutoMapper 設定與操作習慣相近的替代套件，所以對於 Mapperly 就沒有太多的關注。
直到寫了「替換映射工具 - 使用 Mapster」這篇文章後才稍微去看看 Mapperly，發現到它和 AutoMapper, Mapster 雖然都是屬於 Mapping 工具，都是做物件對映轉換的處理，但設定與使用上就有蠻大的差別，所以寫篇文章做個簡單的紀錄。
其實四年前就已經將手邊專案由原本所使用的 AutoMapper 以 Mapster 取代了。
起初的原因是效能考量，因為 AutoMapper 的效能一直被人詬病，但也因為 AutoMapper 的優點在於功能豐富、配置設定靈活，能夠處理複雜的 Mapping 需求，以致於我在帶新人的時候還是以 AutoMapper 為主，但是前些日子得知 AutoMapper 在之後也將走上商業化（跟 Fluent Assertions 一樣），所以就藉此來寫篇文章簡單介紹 Mapster。
今天 (2025-04-06) 早上在 Facebook - 台灣 .NET 技術愛好找論壇裡看到 Will 保哥轉貼了一則 X 貼文，
要檢查一個集合物件是否有元素在內，會使用哪一種語法來檢查 …
在 C# 開發中，經常需要判斷一個集合是否有包含任何元素。雖然這是一個簡單的判斷，但其實背後有不少值得探討的細節。就來瞭解這四種常見的做法，並分析它們的優缺點與適合的使用情境。
過去工作專案大多使用 RabbitMQ 來處理訊息佇列，RabbitMQ 的幾種模式（Direct, Topic, Fanout）都有使用，因為都可以解決大多數的應用情境，所以就沒有想要去使用 Kafak，畢竟多建立一套服務就需要再多花時間去維護。
一直以來也想要找個時間來玩玩 Kafka，於是就利用週末時間學習怎麼使用 Docker 架設服務，程式開發練習怎麼使用 Confluent.Kafka，這是一篇學習筆記。
之前寫了一篇「使用 Channels 與 BackgroundService 實作生產者-消費者模式（Producer-Consumer Pattern）」是使用 Channels 與 BackgroundService 來實作，而這一次就來改用 Wolverine 這個套件來試試看。
有關 Wolverine 這個套件我也看了好久，一直想拿來試試看，會想要用這個套件，主要是它是一個輕量化的工具，適合用於整合訊息佇列、事件驅動設計和後台任務處理。
而且也因為適合用於整合訊息佇列、事件驅動設計，所以支援了許多第三方服務，例如：RabbitMQ, Kafaka, MQTT, AzureServiceBux, AmazonSqs 等，所以打算之後也繼續玩玩 Wolverine。
上一篇「背景常駐執行計時工作 - 使用 BackgroundService 與 PeriodicTimer」介紹了使用 BackgroundService 與 PeriodicTimer 實作計時的工作處理。
但如果有時候一些工作處理並不是每幾秒鐘或每幾分鐘、每幾個小時這樣的週期行為時，使用 PeriodicTimer 就無法滿足這樣的需求，而在使用 Hangfire 建立 Recurring Job 時都會使用到 Cron Expression 去定義工作的執行週期，而就有看到這麼一個 NuGet 套件就有提供這樣的功能，所以就拿來試試看。
背景常駐執行計時工作的實作方式有很多種，而我習慣在 ASP.NET Coe Web Application 使用 BackgroundService 然後搭配 Task.Delay 的方式來完成計時執行工作的處理，而在 .NET 6 提供了 PeriodicTimer 後就可以更方便的處理計時工作，這篇就來認識執行計時工作的幾種實作方式。
前面分享的兩篇文章，分別介紹了 Microsoft.Bcl.TimeProvider 和 AutoFixture 的 AutoData
另外在寫測試時，可以使用 FakeTimeProvider 去做抽換，就可以設定時區、時間來完成測試情境的執行。
那麼是不是也可以用 AutoData 的特性，讓我們在寫測試的時候可以省下建立 FakeTimeProvider 的步驟呢？當然可以，不過需要先瞭解該怎麼做、可以怎麼做以及應該如何做。