componentClassName is null in the component
componentClassName is null in the component
- 0
componentClassName is null in the component
在開發系統時,如果測試情境的輸出會有許多資料類別並且要驗證很多欄位時,會利用 object graph 比對整個結果是否和預期一致。
現在我的專案裡有個 CustomerRootData 類別,裡頭屬性為十幾個不同型別的子集合,每個類別都有 UpdateTime、UpdateUser 這兩個欄位,但這兩個欄位是在程式執行當下才寫進去的,不屬於測試驗證的重點,在寫測試的時候常常陷入重複設定的地獄。
於是在 AwesomeAssertions / AwesomeAssertions Object Graphs 的架構下,想辦法在做比對時去做到比較方便省事的設定方法,讓我輕鬆地去排除指定的欄位。
在找尋資料、解決方法的同時,也讓我得知不一樣的處理方式,將這些處理方式用文章記錄下來,也提供給大家做個參考。
其實這也不是新聞了,早在今年 1/15 時大家就已經知道並且被商業授權的費用給嚇了一大跳(每個人 $129.95 USD)。
現在特地寫一篇是因為上週因為 AutoMapper 將要變成商業化授權而寫了兩篇文章介紹替代套件,就想到好像並沒有對於 Fluent Assertions 轉變為商業授權去寫一篇文章與替代方案,於是就以 Fluent Assertions 從 v8.0.0 起轉為商業授權,簡單寫了這篇去說明授權限制、專案應對策略,以及替代的 Assertion Library,提供給大家做個參考。
調整設定搭配命令列模式 , 快速進行 SQL Server 安裝
寫個存取DB小功能
Drill Down,常被翻譯或解讀為深層探究、向下鑽取、深入探索、向下切入、…這描述與形容我都覺得很傳神,也很有意境。在層層疊疊嵌套式結構化資料的架構中,由廣入深的探究底層的資料與有用的訊息,正是資料分析與探勘的必要手段。(系列文章實作練習下載)
Mapperly 在以前找尋替代 AutoMapper 的時候就有看過,但當時著重在與 AutoMapper 設定與操作習慣相近的替代套件,所以對於 Mapperly 就沒有太多的關注。
直到寫了「替換映射工具 - 使用 Mapster」這篇文章後才稍微去看看 Mapperly,發現到它和 AutoMapper, Mapster 雖然都是屬於 Mapping 工具,都是做物件對映轉換的處理,但設定與使用上就有蠻大的差別,所以寫篇文章做個簡單的紀錄。
整合 GitHub Action 在 Self Host Runner - 不分平台篇
整合 GitHub Action 在 Self Host Runner - Android 篇
整合 GitHub Action 在 Self Host Runner - iOS 篇
建立 GitHub Action Self Host Runner
其實四年前就已經將手邊專案由原本所使用的 AutoMapper 以 Mapster 取代了。
起初的原因是效能考量,因為 AutoMapper 的效能一直被人詬病,但也因為 AutoMapper 的優點在於功能豐富、配置設定靈活,能夠處理複雜的 Mapping 需求,以致於我在帶新人的時候還是以 AutoMapper 為主,但是前些日子得知 AutoMapper 在之後也將走上商業化(跟 Fluent Assertions 一樣),所以就藉此來寫篇文章簡單介紹 Mapster。
Javascript多執行緒+非同步應用動態載入大量元素到Dom
加一個簡單api
Get Files from Directory
Must have pro license to use this module.
在 python 利用 FastAPI 建立 API 非常的簡單,同樣的,要測試它也非常地容易,這裡我會使用一個簡單的例子,演練 pytest 測試 API (FastAPI)
今天 (2025-04-06) 早上在 Facebook - 台灣 .NET 技術愛好找論壇裡看到 Will 保哥轉貼了一則 X 貼文,
要檢查一個集合物件是否有元素在內,會使用哪一種語法來檢查 …
在 C# 開發中,經常需要判斷一個集合是否有包含任何元素。雖然這是一個簡單的判斷,但其實背後有不少值得探討的細節。就來瞭解這四種常見的做法,並分析它們的優缺點與適合的使用情境。
對於階層式的資料,除了利用紀錄父階層的 Id 之外,SQL Server 可以使用其特別專屬的 hierarchyid 來做處理
pytest 是一個功能強大且靈活的 Python 測試框架,身為一個開發者學好怎麼寫測試是基本的必要條件,以下是我對 pytest 的使用心得。
CoPilot 與 Google Gemini哪一個比較「人性化」?
之前有介紹過 TestContainers 在 .NET 的使用方式 傳送們,同樣的 Python 也可以使用它,就不再贅述太多;我將使用 WSL + Python 環境搭建起開發環境。
Table容器是Power Query中處理結構化數據的核心工具,也就是我們俗稱的資料表(Data Table)。透過行、列方式儲存資料,可以執行篩選、合併、轉置等多樣操作,滿足數據清理與轉換的需求。Table容器在資料整合中更扮演重要角色,可以整合多個來源數據,也是進行複雜分析的基礎,能與Excel及Power BI無縫對接,支援樞紐分析、動態報表等。熟練掌握Table容器不僅能提升工作效率,還有助於應對多樣化的數據分析需求,是瞭解與學習Power Query的關鍵一步。
經過這一輪的List(清單)實作,相信您對清單的結構、語法與特性,有些基本認識了吧!接著,我們就來看看另一個Power Query容器:Record(記錄)的特性。
除了使用[向下切入]或點開超連結的操作來執行擷取List元素之內容的查詢步驟外,也可以透過程式碼的編輯來達到相同的目的。這時候就一定要懂得List索引值的概念了。