之前寫了一篇「使用 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 的步驟呢？當然可以，不過需要先瞭解該怎麼做、可以怎麼做以及應該如何做。
這是一篇借花獻佛、拾人牙慧的文章，之前有寫過這麼一篇文章「單元測試使用 AutoFixture.AutoNSubstitute」
當時是使用了 AutoFixture.AutoNSubsititute 來減少測試類別裡相依類別的 Stub 建立步驟，用了很奇怪的方式來解決我當時的煩惱。
直到我進入到另一個團隊後，才知道可以藉由 AutoFixture.AutoData 做到更為簡單與彈性的解決方式，這篇就來簡單介紹怎麼做。
我想很多人看到標題後都會直接想
「程式裡直接用 DateTime 難道錯了嗎？」
「DateTime 用得好好的，為什麼要改用 Microsoft.Bcl.TimeProvider ?」
「我又不必寫測試，我就是要用 DateTime！」
我也管不著各位想怎麼用、想怎麼寫程式，只是看到很多有關於交易處理的程式都是跟時間判斷有關，而且有著種種原因而沒有寫測試，就讓人覺得那些產品妥當嗎？
而且一遇到 DateTime 的處理，就會卡在不知道如何寫測試。
所以就來寫這一篇簡單介紹 Microsoft.Bcl.TimeProvider
