在微服务项目里，业务规则往往会分散到多个小服务中，比如订单服务、库存服务、价格服务。以订单折扣计算为例，同一个接口会根据订单金额、会员等级、促销活动等参数返回不同结果。如果为每一组输入都复制一个测试方法，测试类会迅速膨胀，而且很多断言逻辑是重复的。NUnit 提供的参数化测试能力可以让一个测试方法接收多组数据，每组数据独立运行，任何一组失败都能直接定位到对应参数。相比 xUnit 的 InlineData 与 MemberData，NUnit 的 TestCase、TestCaseSource、ValueSource 组合更加灵活，尤其适合 .NET 微服务中规则密集型的代码。下面从基础特性开始，逐步过渡到 HTTP 接口和集成测试场景。
一、TestCase 与 ExpectedResult：快速建立参数化用例
NUnit 中最直接的参数化方式是 [Test] 配合 [TestCase]。每个 [TestCase] 表示一组输入，NUnit 会为每组输入创建独立的测试用例。ExpectedResult 用来声明期望返回值，特别适合纯函数式业务逻辑。这样测试运行器会显示每个参数组合的名称和结果，而不用手动写循环或多份重复的测试方法。
以一个 OrderService 的 CalculateDiscount 方法为例，它接收订单金额和会员等级，返回折后金额。假设规则是 Gold 打 85 折、Silver 打 9 折、Bronze 打 95 折，并且需要覆盖四种典型金额。下面是使用 TestCase 与 ExpectedResult 的测试代码。
[TestFixture]
public class OrderServiceTests
{
private OrderService _service;
[SetUp]
public void SetUp()
{
_service = new OrderService();
}
[Test]
[TestCase(100, "Gold", ExpectedResult = 85)]
[TestCase(200, "Gold", ExpectedResult = 170)]
[TestCase(100, "Silver", ExpectedResult = 90)]
[TestCase(100, "Bronze", ExpectedResult = 95)]
public decimal CalculateDiscount_ShouldApplyCorrectRate(decimal amount, string level)
{
return _service.CalculateDiscount(amount, level);
}
}
这个测试虽然简单，但已经体现了参数化测试的核心优势：四行 TestCase 覆盖四种业务组合，而不需要四个几乎相同的测试方法。测试失败时，控制台会指出是哪个 TestCase 失败，例如 Expected 85 But was 90，同时展示传入参数。需要注意的是 ExpectedResult 只适用于有返回值的测试方法，如果方法返回 void 或需要断言异常，则要使用 Throws 或普通断言。
二、TestCaseSource 与 TestCaseData：管理更复杂的数据集
当测试数据超过十几组，或者需要从外部文件、数据库、共享夹具中读取时，直接在特性上堆 TestCase 会变得难以维护。NUnit 的 TestCaseSource 可以把数据源指向一个静态属性、方法或独立的类。TestCaseData 提供了 Returns、Throws、SetName 等链式方法，让数据声明更接近自然语言，也更容易复用。
下面的 DiscountCases 属性返回 IEnumerable<TestCaseData>，每个 TestCaseData 都描述一组输入以及期望结果。测试方法通过 TestCaseSource(nameof(DiscountCases)) 引用它。这样测试方法和测试数据彻底分离，新增用例时只需要修改数据源。
public static IEnumerable<TestCaseData> DiscountCases
{
get
{
yield return new TestCaseData(100, "Gold").Returns(85);
yield return new TestCaseData(200, "Gold").Returns(170);
yield return new TestCaseData(100, "Silver").Returns(90);
yield return new TestCaseData(100, "Bronze").Returns(95);
yield return new TestCaseData(0, "Gold").Returns(0);
yield return new TestCaseData(-10, "Gold").Throws(typeof(ArgumentException));
}
}
[Test]
[TestCaseSource(nameof(DiscountCases))]
public decimal CalculateDiscount_ShouldReturnExpectedResult(decimal amount, string level)
{
return _service.CalculateDiscount(amount, level);
}
TestCaseData 的 SetName 可以给用例起中文名称，在测试资源管理器中看到的不再是通用的参数拼接，而是业务含义明确的描述。对于微服务团队来说这一点很重要，因为业务人员和测试人员可以通过用例名称快速理解规则。除了静态属性，TestCaseSource 还可以指向一个方法，方法可以接收上下文参数，用于从配置中动态生成数据。比如读取 appsettings.json 中的折扣规则，再转化成 TestCaseData 集合。
三、微服务 HTTP 接口的参数化集成测试
单元测试只能验证服务内部逻辑，但微服务最终通过 HTTP 暴露能力。参数化测试同样可以用于集成测试，验证路由、模型绑定、状态码和响应体。ASP.NET Core 提供 WebApplicationFactory<TEntryPoint>，可以在内存中启动完整的应用管道，不需要真实网络监听。把 NUnit 与 WebApplicationFactory 结合，就能为多个输入场景快速编写接口测试。
下面示例假设订单微服务有一个 GET /api/orders/discount 接口，接收 amount 和 level 两个查询参数。通过 TestCase 传入不同的 URL 片段和期望的 HttpStatusCode。SetUp 中创建 HttpClient，TearDown 中释放资源。查询字符串中的 & 在 C# 字符串里是普通字符，但放在 HTML 源码中需要写成 & 才能正确显示为 &。
using System.Net;
using Microsoft.AspNetCore.Mvc.Testing;
[TestFixture]
public class OrderEndpointTests
{
private HttpClient _client;
[SetUp]
public void SetUp()
{
_client = new WebApplicationFactory<Program>().CreateClient();
}
[TearDown]
public void TearDown()
{
_client.Dispose();
}
[Test]
[TestCase("/api/orders/discount?amount=100&level=Gold", HttpStatusCode.OK)]
[TestCase("/api/orders/discount?amount=200&level=Silver", HttpStatusCode.OK)]
[TestCase("/api/orders/discount?amount=-1&level=Gold", HttpStatusCode.BadRequest)]
[TestCase("/api/orders/discount?amount=100&level=Unknown", HttpStatusCode.BadRequest)]
public async Task DiscountEndpoint_ShouldReturnExpectedStatus(string url, HttpStatusCode expected)
{
var response = await _client.GetAsync(url);
Assert.That(response.StatusCode, Is.EqualTo(expected));
}
}
这种用法有两个细节需要注意。一是查询字符串中的 & 必须按照 HTML 转义规则处理，否则在查看测试报告或网页预览时可能被误解析；二是每个参数化用例都会执行一次 SetUp 和 TearDown，默认情况下 NUnit 不会在 TestCase 之间共享 SetUp，因此测试之间隔离性很好。如果接口有写操作，建议在 TearDown 或 OneTimeTearDown 中清理数据库，避免参数组合之间相互影响。
对于返回体校验，可以在测试方法中反序列化 JSON，根据参数组合断言折扣金额。此时 TestCase 可以增加第三个参数 expectedDiscount，也可以使用 TestCaseSource 返回完整 DTO 对象。参数化使接口测试从只覆盖成功路径，扩展到覆盖边界、非法输入、权限不足等场景，而不需要复制多个测试方法。
四、提升参数化测试可维护性的几个实践
参数化测试最大的风险是失去可读性，尤其是单个测试方法挂了太多 TestCase 时。建议按照业务能力拆分测试类，例如 OrderServiceTests、DiscountEndpointTests，不要让一个测试方法承担过多职责。数据量超过二十组时，优先使用 TestCaseSource 并把数据集中到独立的静态类中。
给每个 TestCaseData 设置 SetName，使用中文或业务术语描述输入与期望。这样做不仅让测试报告更友好，也有助于在失败时快速定位。另一个技巧是避免在数据源中放入复杂对象，改用简单的值类型和字符串，通过工厂方法在测试内部构造对象。例如测试用户输入时不要直接传整个 User 对象，而是传 id 和 role，在测试方法中调用 CreateUser(id, role)。
还可以结合 ValueSource 进行笛卡尔积式测试，但要谨慎使用。Values 和 ValueSource 会把所有参数值相互组合，数量容易爆炸。比如 10 个金额乘 5 个等级就是 50 个用例，如果逻辑本身有依赖，最好改用 TestCaseSource 精确控制组合。最后，微服务集成测试的时间开销比单元测试大，建议在 CI 中把参数化单元测试和参数化集成测试分开，单元测试每次提交运行，集成测试在合并或夜间构建中运行。
NUnit参数化测试.NET微服务单元测试修改时间：2026-09-21 13:44:20