系列:從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案(3/10)
Skills 的觸發困境與 Custom Prompts 的過渡方案
系列:從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案(2/10)
從鐵人賽 30 天到 29 個 Agent Skills — 背景、願景與知識體系
系列:從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案(1/10)
鐵人賽系列文章導讀 — 重啟挑戰:老派軟體工程師的測試修練
2025 年 8 月到 9 月,我參加了 iThome 鐵人賽,花了 30 天寫完「重啟挑戰:老派軟體工程師的測試修練」這個系列。一直沒有在部落格這邊正式介紹過,趁這個機會寫一篇導讀,讓大家在還沒有把 30 篇全部看完也能瞭解裡面在講什麼。
30 天的內容從最基本的「為什麼要寫測試」一路寫到 Testcontainers、.NET Aspire 整合測試、TUnit,每一篇都有技術介紹說明、程式碼範例,以及我自己在專案裡踩過的坑。如果你對 .NET 測試有興趣但不確定要從哪裡開始看,這篇可以幫你省點時間。
另外,完賽之後我把這 30 天的測試知識重新整理成了 29 個 Agent Skills,讓 AI 可以直接拿來用。後續會有一系列文章介紹 `dotnet-testing-agent-skills` 這個專案 — 從 Agent Skills 到 Agent Orchestration 的完整方案。所以這篇鐵人賽導讀也算是後續系列的起點,先從源頭說起。
AwesomeAssertions / FluentAssertions 快速排除更新欄位
在開發系統時,如果測試情境的輸出會有許多資料類別並且要驗證很多欄位時,會利用 object graph 比對整個結果是否和預期一致。
現在我的專案裡有個 CustomerRootData 類別,裡頭屬性為十幾個不同型別的子集合,每個類別都有 UpdateTime、UpdateUser 這兩個欄位,但這兩個欄位是在程式執行當下才寫進去的,不屬於測試驗證的重點,在寫測試的時候常常陷入重複設定的地獄。
於是在 AwesomeAssertions / AwesomeAssertions Object Graphs 的架構下,想辦法在做比對時去做到比較方便省事的設定方法,讓我輕鬆地去排除指定的欄位。
在找尋資料、解決方法的同時,也讓我得知不一樣的處理方式,將這些處理方式用文章記錄下來,也提供給大家做個參考。
Fluent Assertions 要付費了,該怎麼辦呢?
其實這也不是新聞了,早在今年 1/15 時大家就已經知道並且被商業授權的費用給嚇了一大跳(每個人 $129.95 USD)。
現在特地寫一篇是因為上週因為 AutoMapper 將要變成商業化授權而寫了兩篇文章介紹替代套件,就想到好像並沒有對於 Fluent Assertions 轉變為商業授權去寫一篇文章與替代方案,於是就以 Fluent Assertions 從 v8.0.0 起轉為商業授權,簡單寫了這篇去說明授權限制、專案應對策略,以及替代的 Assertion Library,提供給大家做個參考。
另一種映射工具 - Mapperly
Mapperly 在以前找尋替代 AutoMapper 的時候就有看過,但當時著重在與 AutoMapper 設定與操作習慣相近的替代套件,所以對於 Mapperly 就沒有太多的關注。
直到寫了「替換映射工具 - 使用 Mapster」這篇文章後才稍微去看看 Mapperly,發現到它和 AutoMapper, Mapster 雖然都是屬於 Mapping 工具,都是做物件對映轉換的處理,但設定與使用上就有蠻大的差別,所以寫篇文章做個簡單的紀錄。
替換映射工具 - 使用 Mapster
其實四年前就已經將手邊專案由原本所使用的 AutoMapper 以 Mapster 取代了。
起初的原因是效能考量,因為 AutoMapper 的效能一直被人詬病,但也因為 AutoMapper 的優點在於功能豐富、配置設定靈活,能夠處理複雜的 Mapping 需求,以致於我在帶新人的時候還是以 AutoMapper 為主,但是前些日子得知 AutoMapper 在之後也將走上商業化(跟 Fluent Assertions 一樣),所以就藉此來寫篇文章簡單介紹 Mapster。
[練習題] C# 中檢查 Collection 是否有項目的幾種方式
今天 (2025-04-06) 早上在 Facebook - 台灣 .NET 技術愛好找論壇裡看到 Will 保哥轉貼了一則 X 貼文,
要檢查一個集合物件是否有元素在內,會使用哪一種語法來檢查 …
在 C# 開發中,經常需要判斷一個集合是否有包含任何元素。雖然這是一個簡單的判斷,但其實背後有不少值得探討的細節。就來瞭解這四種常見的做法,並分析它們的優缺點與適合的使用情境。
初試 Kafka - 實作生產者-消費者模式(Producer-Consumer Pattern)
過去工作專案大多使用 RabbitMQ 來處理訊息佇列,RabbitMQ 的幾種模式(Direct, Topic, Fanout)都有使用,因為都可以解決大多數的應用情境,所以就沒有想要去使用 Kafak,畢竟多建立一套服務就需要再多花時間去維護。
一直以來也想要找個時間來玩玩 Kafka,於是就利用週末時間學習怎麼使用 Docker 架設服務,程式開發練習怎麼使用 Confluent.Kafka,這是一篇學習筆記。
- 1
- 2