鐵人賽系列文章導讀 — 重啟挑戰:老派軟體工程師的測試修練

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 的完整方案。所以這篇鐵人賽導讀也算是後續系列的起點,先從源頭說起。

...繼續閱讀 »

使用 Fine Code Coverage 取得程式碼覆蓋範圍

這是 Visual Studio 裡的一個延伸模組 (Extension),大約在四五年前在 Visual Stuidio 2019 時就已經發佈的一個工具,而我在過去帶新人教單元測試時都會介紹這個工具,透過這個工具取得測試的程式碼覆蓋範圍。

因為我平常的開發工具是使用 JetBrains Rider,已經有內建 Code Coverage 的功能,我只有在做教學或寫文件、找問題、重現別人問題情境的時候才會開啟 VS2022,在三月底四月初時這個工具產生 Code Coverage 的功能都還正常,但是卻在前幾天因為在整理文件時久違地開啟 Visual Studio 2022 並且要取得 Code Coverage 卻出現了異常,在找尋問題原因以及嘗試如何解決花了不少的時間,最後是順利地找到原因並且排除了狀況。於是就寫了這篇文章來介紹工具並說明要怎麼解決異常狀況。

...繼續閱讀 »

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,提供給大家做個參考。

...繼續閱讀 »