Blazor 组件单元测试核心是用 bUnit 搭配 xUnit（或 NUnit），不跑浏览器、不依赖 DOM，专注验证组件逻辑、渲染输出和交互行为。关键不在“能不能测”，而在于“怎么搭得轻、写得清、断言得准”。
搭测试项目：三步到位
新建 xUnit 测试项目，引用待测的 Blazor 客户端项目，并添加 bUnit：
用 CLI：dotnet new xunit -n MyApp.Tests，再
dotnet add reference ../src/MyApp.Client加 bUnit 包：
dotnet add package bunit --version 1.24.2（推荐稳定版） 确保测试项目启用可空引用类型（
<nullable>enable</nullable>），与被测组件保持一致
写测试类：继承 TestContext 或自定义基类
不用从零初始化上下文，直接用 bUnit 提供的
TestContext： 最简写法：
var ctx = new TestContext();，然后
ctx.RenderComponent<mycomponent>()</mycomponent>若用 BootstrapBlazor 等封装库，继承
BootstrapBlazorTestBase，它已预配置服务（如本地化、缓存、路由） 需注入服务时，在
ctx.Services中注册模拟实现，例如
ctx.Services.AddSingleton<iweatherservice>(new MockWeatherService())</iweatherservice>
测什么？聚焦三个真实场景
别堆覆盖率，优先覆盖用户能感知的行为：
参数驱动渲染：传不同Color、
Disabled值，检查生成的 class 或是否禁用按钮 —— 用
[Theory]+
[InlineData]参数化 事件交互：触发
@onclick、
@oninput，验证状态变更或回调是否执行 ——
cut.Find("button").Click(); 后断言 cut.Instance.IsLoading子组件与内容投影：检查
<childcomponent>@ChildContent</childcomponent>是否正确渲染，或
RenderFragment内容是否出现
断言技巧：看 HTML 还是看状态？
两者结合更可靠：
查 DOM 输出：cut.MarkupMatches("<button class='\"btn' btn-primary>Save</button>")
查组件实例状态：Assert.True(cut.Instance.IsEnabled);查事件是否触发：
var clicked = false; cut.SetParametersAndRender(p => p.Add(x => x.OnClick, () => clicked = true)); cut.Find("button").Click(); Assert.True(clicked);
基本上就这些。不复杂但容易忽略的是：服务模拟要到位、参数组合要覆盖边界值、避免过度断言内部实现细节。测得稳，改得才放心。
