之前有介紹過 ReportGenerator，支援多種 Code Coverage 測試涵蓋率套件
今天要來介紹 Coverlet，他除了支援 Azure DevOps 的 ReportGenerator 輸出 html，還可以整合 VS IDE 的 Fine Code Coverage，不論是開發還是 CI 自動化都兼顧到了
當我們要針對商業邏輯測試時，可能需要隔離 EFCore DbContext，搭配 Mock Framework 可以快速地建立測試替身假的 DbContext，自從 EF Core 的 In-Memory 出現之後，建立 DbContext 測試替身這件事，就變得輕鬆許多了
以往在 NetFx 在專案的 AssemblyInfo.cs 加上 System.Runtime.CompilerServices.InternalsVisibleToAttribute("TestProject1")，就可以讓 "TestProject1" 存取 NetFx 專案內的 internal 成員；這技巧通常用於測試，既可隱藏，又可測試，真的好棒。
現在，新版的 .NET Project SDKs 已經沒有包含 AssemblyInfo.cs 靜態檔案了，作法就要做一些調整了
當測試案例越來越多的時候，執行的時間會越來越長，這時候就可以靠並行測試 (Parallel Test)，來縮短測試時間，只要確定測試案例之間沒有共用資源，就可以使用囉
我的作法是在測試專案用OWIN把 WebApp 掛起來，測試案例便可直接打進 Web API，需要外部注入來改變內部狀態時，就不能像以前呼叫 Class，我想到了一些作法，比如組態擋、#if、Header，這裡就分享 Header 的做法
https://dotblogs.com.tw/yc421206/archive/2014/07/28/146082.aspx 根據上篇，可輕易地在專案建立出不同環境的組態設定，但是 TFS 上的 Build 沒有正常的切換環境，測試專案的連線字串沒有根據我期望的切換，不像 Web 那樣，原來還需要一些設定，以下分享我成功的方法。
結果與期望比對，是測試程式碼中最重要的一個步驟，就是用它來取代人眼比對，有關物件比對 91哥的文章有非常詳細的介紹：
https://dotblogs.com.tw/hatelove/2014/06/06/how-to-assert-two-collection-equal
https://dotblogs.com.tw/hatelove/2016/03/28/compare-object-equality-with-expected-objects
當測試程式碼用的是複雜型別，會比對型別中的屬性狀態(值)，用它來決定是否通過驗證，最直接的方式就是跑迴圈一個一個比，這樣做不是很聰明，也不夠快，太費力
我會使用以下物件來完成我的工作
在這裡我分享我常用的比對方式...
開發 Web 或多或少會使用到 HttpContext.Current，為了專注測主要邏輯，會隔離 HttpContext.Current，不要因為它而導致測試無法運行，我在這裡列出了一些隔離技巧
集成測試主要是測試個元件之間的互動是否如預期，在這個階段的測試，我會把程式進入點 UI Layer 換成單元測試專案，由測試專案取代之，為什麼不是直接從UI測，原因很簡單，因為 UI 的變化太快了，一方面為了減少因 UI 改變而衍生出額外的工作，另一方面則為了提高測試程式碼的重用性，所以我會從 BLL 測試
三層式架構，物件彼此之間的關係，如下圖：
[Visual Studio 2013][Entity Framework] 在 Unit Test 使用 Code Fist for SqlLocalDb
解決 The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded 問題