余小章 @ 大內殿堂

pytest 是一個功能強大且靈活的 Python 測試框架，身為一個開發者學好怎麼寫測試是基本的必要條件，以下是我對 pytest 的使用心得。

之前有介紹過 ReportGenerator，支援多種 Code Coverage 測試涵蓋率套件

今天要來介紹 Coverlet，他除了支援 Azure DevOps 的 ReportGenerator 輸出 html，還可以整合 VS IDE 的 Fine Code Coverage，不論是開發還是 CI 自動化都兼顧到了

當我們要針對商業邏輯測試時，可能需要隔離 EFCore DbContext，搭配 Mock Framework 可以快速地建立測試替身假的 DbContext，自從 EF Core 的 In-Memory 出現之後，建立 DbContext 測試替身這件事，就變得輕鬆許多了

測試使用 EF Core 的程式碼 - EF Core | Microsoft Docs

以往在 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

當測試程式碼用的是複雜型別，會比對型別中的屬性狀態(值)，用它來決定是否通過驗證，最直接的方式就是跑迴圈一個一個比，這樣做不是很聰明，也不夠快，太費力

我會使用以下物件來完成我的工作

1. FluentAssertions
2. SpecFlow

在這裡我分享我常用的比對方式...

開發 Web 或多或少會使用到 HttpContext.Current，為了專注測主要邏輯，會隔離 HttpContext.Current，不要因為它而導致測試無法運行，我在這裡列出了一些隔離技巧

集成測試主要是測試個元件之間的互動是否如預期，在這個階段的測試，我會把程式進入點 UI Layer 換成單元測試專案，由測試專案取代之，為什麼不是直接從UI測，原因很簡單，因為 UI 的變化太快了，一方面為了減少因 UI 改變而衍生出額外的工作，另一方面則為了提高測試程式碼的重用性，所以我會從 BLL 測試

三層式架構，物件彼此之間的關係，如下圖：