mrkt的程式學習筆記

本來應該在 Part.3 這一篇就應該做個完結，但還是有一件事情要交代，所以又開了一篇來做說明，這一篇會有關於前陣子所發的文章「準備 Repository 單元測試的測試資料 - 產生匯入資料的 SQL Script」有關，在「Repository 測試使用 LocalDB - Part.3」裡面所使用的是 CSV 匯入測試資料，而接著就會說明使用 Insert SQL Command 的方式匯入測試資料的做法。

接續上一篇「Repository 測試使用 LocalDB - Part.2 」的內容，在上一篇已經完成使用 Entity Framework 建立與移除 LocalDB 的類別和方法，在第一篇「Repository 測試使用 LocalDB - Part.1 」也說明了要受測試的目標類別與方法，另外也建立了要在單元測試裡所使用的測試資料。

這一篇就要完成 Repository 的單元測試，會用到前面兩篇所建立的類別與資料，所以請各位要仔細看清楚囉。

接續上一篇「Repository 測試使用 LocalDB - Part.1 」的內容，這一篇將會介紹如何透過 Entity Framework 的方法建立與移除 LocalDB。

之前曾經試過以程式碼建立 LocalDB 的方式，例如使用指令碼的方式在執行 Repository 測試前建立 LocalDB、執行測試後再移除 LocalDB，這樣的做法也真的可行，不過卻相當不穩定，當測試全部都執行正確時是不會有問題，但是一旦當一個錯誤發生問題時，建立的 LocalDB instance 就會被鎖住而無法正確釋放、移除，這樣的問題一直困擾著我很久。

接下來的幾篇文章將會介紹一個穩定而且不會發生測試失敗就把 LocalDB 鎖住的方式，藉助 Entity Framework 所提供的類別與方法來完成 Repository 測試的 LocalDB 建立與移除，讓我們能夠以更為簡易的方式來完成 Repositoy 的單元測試。

隨著單元測試的數量越來越多，而且在公司裡所開發的專案大部分還是使用 Dapper 來存取資料，所以 Repository 的單元測試就開始暴增，原本使用 CSV 檔案來匯入測試資料到 LocalDB 的前置作業就會成為讓整體測試作業執行時間緩慢的原因之一。

為了解決使用 CSV 檔案匯入測試資料會因為資料轉換而使得測試時間拉長的情況，所以乾脆使用 SQL Dumper 及 ApexSQL Script 工具匯出 SQL Script 來直接匯入測試資料。

對於使用 Dapper 做為資料讀取異動操作的開發者來說，應該是相當方便，目前我目前的工作環境裡，幾乎新開發的專案裡都已經使用 Dapper 以及快速產生相對映類別的方法。

另外就是有關於單元測試的部分，公司裡的各個開發團隊也陸續在專案裡導入單元測試，不管是應用展示層或是商業邏輯層都會嘗試去做單元測試，唯獨資料存取層的單元測試卻是比較少人會去做，當然資料存取層的單元測試是否要做，這並沒有一定的標準答案，而我所認知的是，只要程式是開發人員去編寫出來的就有必要做測試，但是資料存取層的測試所牽涉到的技術會比較多一些，也關係到資料存取所使用的方式，都是影響要不要做測試的因素。

而這一篇所要介紹的內容也就是在做資料存取層的單元測試時的其中一個環節。

以往在針對方法的執行結果進行資料排序的驗證時，比較直接的做法就是取得 collection 的第一筆與最後一筆，然後再依據用什麼條件做排序去比較兩筆資料，例如使用日期為條件而且是由新到舊的排序，那麼第一筆資料必須要比最後一筆資料的日期還要新，大概是用這樣的方式做資料排序的驗證。

不過這樣的做法還蠻土砲的，所以就用 Fluent Assertions 所提供的方法來處理吧。

資料存取層的測試… 真的比較麻煩

有些資料是已經存在於資料庫，例如定期匯入或排程計算的資料結果，如果在程式裡使用 AutoFixture 或是假資料來做測試，有時候會出現一些問題點，所以就會從資料庫直接取得一部份的資料來做為測試資料，匯出的方式有很多種，而這一篇所介紹的方式就是其中一種，我是希望可以盡量使用程式的方式來處理而不是以 Insert Script 的方式來，不過這不是絕對的做法，就看各位習慣什麼方式，或許大家有更好以及更好管理的方法。

這一篇是介紹「Fluent Assertions」這個好用的測試輔助套件。