Blazor 使用 bUnit 进行组件单元测试教程_技术教程

bUnit测试Blazor组件的核心是内存中模拟渲染环境、触发交互并断言HTML输出。需创建xUnit测试项目，引用bunit、bunit.web等包；用TestContext和RenderComponent渲染组件；支持参数传递、事件回调捕获和服务注入；异步操作需WaitForState等待状态更新。

Blazor 组件用 bUnit 做单元测试，核心是模拟渲染环境、触发交互、断言渲染结果——不启动真实浏览器，也不依赖服务器，纯内存中完成。

准备测试项目和基础配置

bUnit 基于 xUnit（也支持 NUnit 和 MSTest），推荐新建一个独立的 xUnit 测试项目，并引用以下 NuGet 包：

bunit（主包，含核心测试工具）
bunit.web（专用于 Blazor WebAssembly 和 Server 的组件测试支持）
Microsoft.AspNetCore.Components.Web（确保与你的 Blazor 版本一致，通常 .NET 6+ 已内置，但测试项目仍需显式引用）

若使用 .NET 8+，确认项目 SDK 是，并添加 net8.0。无需启动 Host 或 WebApplication，bUnit 自带轻量渲染器。

编写第一个组件测试

假设你有一个简单组件 Counter.razor：

@page "/counter"
Count: @currentCount


@code {
    private int currentCount = 0;
    private void IncrementCount() => currentCount++;
}

对应测试代码如下：

[Fact]
public void Counter_IncrementsWhenClicked()
{
    // Arrange
    using var ctx = new TestContext();
    var cut = ctx.RenderComponent();

    // Act
    cut.Find("button").Click();

    // Assert
    cut.MarkupMatches(@"Count: 1
");
}

说明：
– TestContext 提供虚拟的 Blazor 渲染环境；
– RenderComponent() 同步渲染组件并返回可操作的 IRenderedComponent；
– Find() 支持 CSS 选择器（如 "button"、"h3"、"#myId"）；
– MarkupMatches() 对比实际渲染 HTML 字符串（忽略空白和属性顺序，语义等价即通过）。

模拟参数、事件和依赖服务

真实组件常接收 [Parameter]、调用 EventCallback 或依赖注入的服务。bUnit 全支持：

传入参数：用 RenderComponent(parameters => parameters.Add(p => p.Title, "My Page"))
捕获回调：定义 EventCallback onInput 参数后，在测试中用 Mock 或 InvocableEventCallback 捕获调用
注入服务：用 ctx.Services.AddSingleton(new MockFooService()) 替换默认实现

例如测试带参数的 Welcome.razor：

@code {
    [Parameter] public string Name { get; set; } = "Guest";
}
Hello, @Name!

测试写法：

[Fact]
public void Welcome_RendersCustomName()
{
    using var ctx = new TestContext();
    var cut = ctx.RenderComponent(parameters => parameters
        .Add(p => p.Name, "Alice"));

    cut.MarkupMatches("Hello, Alice!");
}

验证异步行为和状态更新

遇到 await、StateHasChanged() 或 OnInitializedAsync，需用 cut.WaitForState(() => ...) 或 cut.WaitForNextRender() 等待更新完成。

例如组件内部加载数据：

@code {
    public string Message { get; private set; } = "Loading...";
    protected override async Task OnInitializedAsync() {
        await Task.Delay(100);
        Message = "Ready!";
    }
}

测试时这样写：

[Fact]
public async Task MyComponent_LoadsMessageAfterDelay()
{
    using var ctx = new TestContext();
    var cut = ctx.RenderComponent();

    // 初始状态
    Assert.Equal("Loading...", cut.Instance.Message);

    // 等待异步初始化完成（最多等 500ms）
    await cut.WaitForState(() => cut.Instance.Message == "Ready!", TimeSpan.FromMilliseconds(500));

    cut.MarkupMatches("Ready!");
}

基本上就这些。bUnit 测试写起来接近“所见即所测”，逻辑清晰、执行快、调试方便。重点不是覆盖所有分支，而是验证组件在关键输入下的输出是否符合预期——比如按钮点击后 UI 是否更新、错误状态是否显示正确提示、参数变化是否触发重渲染。不复杂但容易忽略的是：别忘了 using 释放 TestContext，避免跨测试污染；CSS 选择器写错、Markup 字符串大小写或空格不一致，都会让 MarkupMatches 失败。