隨著單元測試的數量越來越多，而且在公司裡所開發的專案大部分還是使用 Dapper 來存取資料，所以 Repository 的單元測試就開始暴增，原本使用 CSV 檔案來匯入測試資料到 LocalDB 的前置作業就會成為讓整體測試作業執行時間緩慢的原因之一。
為了解決使用 CSV 檔案匯入測試資料會因為資料轉換而使得測試時間拉長的情況，所以乾脆使用 SQL Dumper 及 ApexSQL Script 工具匯出 SQL Script 來直接匯入測試資料。
對於使用 Dapper 做為資料讀取異動操作的開發者來說，應該是相當方便，目前我目前的工作環境裡，幾乎新開發的專案裡都已經使用 Dapper 以及快速產生相對映類別的方法。
另外就是有關於單元測試的部分，公司裡的各個開發團隊也陸續在專案裡導入單元測試，不管是應用展示層或是商業邏輯層都會嘗試去做單元測試，唯獨資料存取層的單元測試卻是比較少人會去做，當然資料存取層的單元測試是否要做，這並沒有一定的標準答案，而我所認知的是，只要程式是開發人員去編寫出來的就有必要做測試，但是資料存取層的測試所牽涉到的技術會比較多一些，也關係到資料存取所使用的方式，都是影響要不要做測試的因素。
而這一篇所要介紹的內容也就是在做資料存取層的單元測試時的其中一個環節。
以往在針對方法的執行結果進行資料排序的驗證時，比較直接的做法就是取得 collection 的第一筆與最後一筆，然後再依據用什麼條件做排序去比較兩筆資料，例如使用日期為條件而且是由新到舊的排序，那麼第一筆資料必須要比最後一筆資料的日期還要新，大概是用這樣的方式做資料排序的驗證。
不過這樣的做法還蠻土砲的，所以就用 Fluent Assertions 所提供的方法來處理吧。
資料存取層的測試… 真的比較麻煩
有些資料是已經存在於資料庫，例如定期匯入或排程計算的資料結果，如果在程式裡使用 AutoFixture 或是假資料來做測試，有時候會出現一些問題點，所以就會從資料庫直接取得一部份的資料來做為測試資料，匯出的方式有很多種，而這一篇所介紹的方式就是其中一種，我是希望可以盡量使用程式的方式來處理而不是以 Insert Script 的方式來，不過這不是絕對的做法，就看各位習慣什麼方式，或許大家有更好以及更好管理的方法。
這一篇是介紹「Fluent Assertions」這個好用的測試輔助套件。
這邊簡單說明 NanoProfiler 的一些設定修改的內容。
之前連著兩篇介紹了 NanoProfiler.Data 在 ADO.NET 與 Dapper 的專案裡的使用情境與安裝說明，而這一篇就接著介紹專案使用 Entity Framework 與 NanoProfiler 的說明。
上一篇「NanoProfiler 對於資料庫存取的監控 - ADO.NET」的最後有講到使用 ADO.NET 進行資料存取處理雖然可以使用 NanoProfiler 將程式的執行效能作監控，但是卻無法將執行的 T-SQL 內容給記錄起來，所以算是一個未完成品。
現在這一篇則是改用 Dapper 取代 ADO.NET 的操作，然後再使用 NanoProfiler.Data 去進行資料存取的監控並且將執行的 T-SQL 給記錄起來。
這一篇來說明對於使用 ADO.NET 進行資料庫存取的 Repository 要如何使用 NanoProfiler.Data 去做到監控與執行 T-SQL 的記錄呈現。
這一篇文章的內容算是拾人牙慧，只是跟大家說別人有提供了方法可以讓我們能夠快速地從 SQL Command 去建立相對映的類別，雖然不是我寫的方法，但還是希望大家可以及早地從弱型別的地獄中快點逃離出來（雖然這麼說是有貶抑弱型別的意味，但看了這麼多年以及很多人所開發的專案，發現到很多問題都是從濫用 DataSet DataTable 等弱型別開始）。