實戰指南：使用 xUnit 和 ASP.NET Core 進行整合測試【完整教程】

引言

整合測試可在包含套用支持基礎結構（如資料庫、檔案系統和網路）的級別上確保套用元件功能正常。 ASP.NET Core 透過將單元測試框架與測試 Web 主機和記憶體中測試伺服器結合使用來支持整合測試。

簡介

整合測試與單元測試相比，能夠在更廣泛的級別上評估套用的元件，確認多個元件一起工作以生成預期結果，包括資料庫、檔案系統、網路裝置等元件。單元測試主要用於測試獨立軟體元件，如類方法，通常使用 fake 或 mock 物件。整合測試使用實際元件，需要更多程式碼和數據處理，執行時間更長。建議將整合測試限制在重要的基礎結構方案上，若可用單元測試或整合測試測試行為，優先選擇單元測試。整合測試中被測試的計畫通常稱為 "SUT" ，用於指代要測試的套用。避免為每種資料庫和檔案系統互動排列編寫整合測試，而是透過一組集中式讀取、寫入、更新和刪除整合測試充分測試這些元件，使用單元測試測試與這些元件互動的方法邏輯，使用 fake 或 mock 物件可加快測試速度。

整合測試實戰

我們在之前的章節中建立了 Sample.Api 和 Sample.Repository 的計畫，現在我們對這個計畫進行整體的整合測試，帶大家來感受一下。

ASP.NET Core 中的整合測試需要以下內容：

整合測試後跟一系列事件，包括常規 「排列」 、 「操作」 和 「斷言」 測試步驟：

上面解釋到了整合測試中被測試的計畫通常稱為 SUT 。我們要測試的計畫 Sample.Api 既是我們的 SUT 。

好了我們開始建立 xUnit的單元測試計畫 ,並添加 Sample.Api 的計畫參照.

整合測試第一步

在我們的單元測試計畫中安裝 Nuget 依賴

PM> NuGet\Install-Package Microsoft.AspNetCore.Mvc.Testing -Version 8.0.4


基礎結構元件（如測試 Web 主機 和記憶體中測試伺服器 ( TestServer )）由 Microsoft.AspNetCore.Mvc.Testing 包提供或管理。使用此包可簡化測試建立和執行。

Microsoft.AspNetCore.Mvc.Testing 包處理以下任務：

將依賴項檔 ( .deps ) 從 SUT 復制到測試計畫的 bin 目錄中。將內容根目錄設定為 SUT 的計畫根目錄，以便可在執行測試時找到靜態檔和頁面/檢視。提供 WebApplicationFactory 類，以簡化 SUT 在 TestServer 中的啟動過程。

概念有點多，後續裏面的概念會慢慢講到。

我們知道 Asp.Net Core 的 Web 計畫計畫是借助 Kestrel 啟動,用整合測試的 TestServer 正是代替了 Kestrel 托管服務的啟動，那我們要測試的計畫就不需要單獨被啟動了。

什麽是 TestServer ?

TestServer ^[1] 用於在整合測試中模擬和啟動應用程式的主機環境。透過建立 TestServer 例項，可以在測試中模擬出一個執行中的應用程式例項，以便進行端到端的整合測試。

在 Microsoft.AspNetCore.Mvc.Testing 中已經預設整合了對 TestServer 的支持所以，不需要額外進行配置。

SUT 環境?

如果未設定 SUT 的環境，則環境會預設為開發環境即 Development 。

向測試計畫公開啟動類 Program

使用 WebApplicationFactory<TEntryPoint> 建立 TestServer 以進行整合測試。 TEntryPoint 是 SUT 的入口點類，通常是 Program.cs 。

有兩種向測試計畫公開 Program 的方法

var builder = WebApplication.CreateBuilder(args);
// ... Configure services, routes, etc.
app.Run();
+ publicpartial classProgram { }


<ItemGroup>
<UsingInclude="Sample.Api" />
<InternalsVisibleToInclude="dotNetParadise.IntegrationTest" />
</ItemGroup>


1. <Using Include="Sample.Api" /> ：這個子元素指定了要在計畫中使用的名稱空間或程式集。在這裏， Sample.Api 被包含在計畫中，以便計畫可以存取和使用該名稱空間或程式集中的內容。

2. <InternalsVisibleTo Include="dotNetParadise.IntegrationTest" /> ：這個子元素用於將內部可見性（ InternalsVisibleTo ）內容套用於計畫，允許指定的程式集（在這裏是 dotNetParadise.IntegrationTest ）存取計畫中的內部成員。這在單元測試或整合測試中非常有用，因為測試計畫通常需要存取被測試計畫的內部成員以進行更全面的測試。

相對來說更推薦使用第一種部份類的形式來對測試計畫公開。

WebApplicationFactory

可以使用預設的 WebApplicationFactory 和自訂的 WebApplicationFactory 來進行整合測試

測試類實作一個類固定常式介面 ( I classFixture )，以指示類包含測試，並在類中的所有測試間提供共享物件例項。

來感受一下

使用預設 WebApplicationFactory 的基本測試

看一下如何使用

public classDefaultWebApplicationFactoryTest : I classFixture<WebApplicationFactory<Program>>
{
privatereadonly WebApplicationFactory<Program> _factory;
publicDefaultWebApplicationFactoryTest(WebApplicationFactory<Program> factory)
{
_factory = factory;
}
[Fact]
publicasync Task GetAll_Query_ReturnOkAndListStaff()
{
//Arrange
var httpClient = _factory.CreateClient();
//act
var response = await httpClient.GetAsync("/api/Staff");
//Assert
//校驗狀態碼
Assert.Equal(HttpStatusCode.OK, response.StatusCode);
//校驗使用者
var users = await response.Content.ReadFromJsonAsync<List<Staff>>();
Assert.NotNull(users);
}
[Fact]
publicasync Task GetConfig_WhenCalled_ReturnOk() {
//Arrange
var httpClient = _factory.CreateClient();
//act
var response = await httpClient.GetAsync("/GetConfig");
//Assert
//校驗狀態碼
Assert.Equal(HttpStatusCode.OK, response.StatusCode);
//校驗使用者
var config = await response.Content.ReadFromJsonAsync<string>();
Assert.NotNull(config);
}
}



看到我們的測試類繼承了 I classFixture 來共享例項物件，並且泛型型別是預設的 WebApplicationFactory<Program>

接下來在我們的 SUT 即 Sample.Api 的 program 中打個斷點來驗證一下

看到了我們測試時預設的 WebApplicationFactory 使用預設配置啟動應用程式主機，包括載入 appsettings.json 等配置檔。

在我們的 appsettings.Development.json 中加了一個配置

{
"Config": "這裏是appsettings.Development.json"
}


GetConfig_WhenCalled_ReturnOk 測試方法看下結果

正確的讀到 appsettings.Development.json 的內容了，從而可以得出我們上面的結論，如果未設定 SUT 的環境，則環境會預設為開發環境即 Development 。

從上面我們看到我們向 SUT 發請求是呼叫的 CreateClient() ：
CreateClient() 方法用於建立一個 HttpClient 例項，用於模擬客戶端與 SUT 進行互動。透過這個 HttpClient ，測試程式碼可以發送 HTTP 請求到應用程式，並驗證應用程式的響應。

總的來說預設的 WebApplicationFactory 提供了一種快速啟動應用程式主機進行整合測試的方式，適用於簡單的測試場景。

自訂 WebApplicationFactory

透過從 WebApplicationFactory<TEntryPoint> 來建立一個或多個自訂工廠，可以獨立於測試類建立 Web 主機配置

我們來建立一個 SampleApiWebAppFactory 的類，然後繼承 WebApplicationFactory<Program>

public classSampleApiWebAppFactory : WebApplicationFactory<Program>
{
protectedoverridevoidConfigureWebHost(IWebHostBuilder builder)
{
builder.ConfigureServices((context, services) =>
{
});
builder.UseEnvironment("Production");
base.ConfigureWebHost(builder);
}
public HttpClient Client()
{
return CreateDefaultClient();
}
}



裏面有 Asp.Net Core 啟動項配置，我們都可以在自訂的 SampleApiWebAppFactory 進行重寫， 自訂的 WebApplicationFactory 提供了一種靈活的方式來客製化應用程式主機的配置，並擴充套件功能以滿足特定的測試需求。透過繼承並重寫 ConfigureWebHost 方法等，開發人員可以對應用程式主機進行自訂配置，包括添加新的服務、中介軟體或修改預設配置，從而在測試環境中模擬特定的場景或功能。

優勢和功能擴充套件：

復雜性和維護：

總的來說，透過自訂的 WebApplicationFactory ，開發人員可以根據具體的測試場景和需求客製化配置和功能，以確保在整合測試中能夠模擬真實的應用程式環境，並進行更全面和準確的測試。這種方式允許開發人員更好地控制應用程式主機的設定，以適應不同的測試需求和場景。

SUT 的資料庫上下文在 Program.cs 中註冊。測試套用的 builder.ConfigureServices 回呼在執行套用的 Program.cs 程式碼之後執行。若要將與套用資料庫不同的資料庫用於測試，必須在 builder.ConfigureServices 中替換套用的資料庫上下文。

builder.ConfigureServices((context, services) =>
{
var descriptor = new ServiceDescriptor(
typeof(DbContextOptions<SampleDbContext>),
serviceProvider => DbContextFactory<SampleDbContext>(serviceProvider, (sp, o) =>
{
o.UseInMemoryDatabase("TestDB");
}),
ServiceLifetime.Scoped);
services.Replace(descriptor);
});

上面用到的 DbContextFactory 方法

privatestatic DbContextOptions<TContext> DbContextFactory<TContext>(IServiceProvider applicationServiceProvider,
Action<IServiceProvider, DbContextOptionsBuilder> optionsAction)
where TContext : DbContext
{
var builder = new DbContextOptionsBuilder<TContext>(
new DbContextOptions<TContext>(new Dictionary<Type, IDbContextOptionsExtension>()));
builder.UseApplicationServiceProvider(applicationServiceProvider);
optionsAction?.Invoke(applicationServiceProvider, builder);
return builder.Options;
}



來寫個整合測試

public class SampleApiTest(SampleApiWebAppFactory factory) : I classFixture<SampleApiWebAppFactory>
{
[Fact]
publicasync Task GetAll_Query_ReturnOkAndListStaff()
{
//Arrange
var httpClient = factory.CreateClient();
//act
var response = await httpClient.GetAsync("/api/Staff");
//Assert
//校驗狀態碼
Assert.Equal(HttpStatusCode.OK, response.StatusCode);
//校驗使用者
var users = await response.Content.ReadFromJsonAsync<List<Staff>>();
Assert.NotNull(users);
}
[Fact]
publicasync Task GetConfig_WhenCalled_ReturnOk()
{
//Arrange
var httpClient = factory.CreateClient();
//act
var response = await httpClient.GetAsync("/GetConfig");
//Assert
//校驗狀態碼
Assert.Equal(HttpStatusCode.OK, response.StatusCode);
//校驗使用者
var config = await response.Content.ReadFromJsonAsync<string>();
Assert.NotNull(config);
}
// 後面測試省略。。。。
}



最後

整合測試是確保套用元件在包含資料庫、檔案系統和網路等基礎結構的級別上正常執行的重要方式。 ASP.NET Core 透過結合單元測試框架、測試 Web 主機和記憶體中測試伺服器來支持整合測試。

在整合測試中，我們評估套用元件在更廣泛的級別上的功能，驗證多個元件一起工作以生成預期結果，包括資料庫、檔案系統、網路裝置等。單元測試主要用於測試獨立的軟體元件，而整合測試需要使用實際元件，涉及更多的程式碼和數據處理，以及更長的執行時間。建議將整合測試限制在重要的基礎結構方案上，優先選擇單元測試或整合測試來測試行為。

在整合測試中，被測試的計畫通常稱為 SUT （ System Under Test ），用於指代要測試的套用。避免為每種資料庫和檔案系統互動編寫獨立的整合測試，而是透過一組集中式的測試來全面測試這些元件，並使用單元測試來測試與這些元件互動的方法邏輯。

透過自訂的 WebApplicationFactory ，可以根據測試需求客製化配置和功能，模擬真實的應用程式環境進行全面和準確的測試。自訂的 WebApplicationFactory 提供了靈活性和客製性，滿足復雜的測試需求，並確保測試環境的準確性。雖然自訂的 WebApplicationFactory 可能需要更多的理解和維護，但能更好地適應不同的測試場景。

整合測試是確保應用程式正常執行的關鍵步驟，透過綜合不同元件的功能來驗證套用的整體表現，提高應用程式的品質和穩定性。

參考資料

[1]

TestServer: https://learn.microsoft.com/zh-cn/dotnet/api/microsoft.aspnetcore.testhost.testserver?view=aspnetcore-8.0