一直想学习一下单元测试 但是感觉比较复杂 而且对于小型的项目 点击的测试 基本上够用了 所以,一直就没有学 现在开始学一下

为什么现在该学单元测试？

常用测试框架

常用的C#单元测试有 XUnit MSTest NUnit

单元测试的方法与规范

单元测试的黄金法则：AAA 模式（Arrange-Act-Assert）

这是所有现代单元测试的底层结构。不管你用 xUnit、NUnit 还是 MSTest，都必须遵循！

规范建议：

• 每个测试方法只测试一个行为
• 每个测试方法必须有且仅有一次 Act

• 用注释或空行分隔 AAA 三部分，提升可读性

  [Fact]
  public void Divide_WhenDivisorIsZero_ThrowsArgumentException()
  {
    // Arrange
    var calculator = new Calculator();
    double dividend = 10;
    double divisor = 0;
  
    // Act & Assert
    var exception = Assert.Throws<ArgumentException>(() => 
        calculator.Divide(dividend, divisor));
  
    // 可选：验证异常信息（更严谨）
    Assert.Equal("除数不能为零", exception.Message);
  }

测试命名规范

语义化 > 简洁
不要叫 Test1()、TestMethod()！
推荐命名：MethodName_State_ExpectedBehavior

✅ 使用下划线 _ 分隔，清晰易读
✅ 用动词短语描述行为（Should / Returns / Throws）
✅ 所有单词首字母大写（PascalCase），保持风格统一

📌 xUnit 官方推荐命名风格：https://xunit.net/docs/style-guidelines

测试粒度：一个测试只测一件事

❌ 错误示范：一个测试干了三件事

[Fact]
public void ShouldWorkCorrectly()
{
    var calc = new Calculator();

    Assert.Equal(5, calc.Add(2, 3));     // 测试加法
    Assert.Equal(6, calc.Multiply(2, 3)); // 测试乘法
    Assert.True(calc.IsPositive(5));     // 测试正数判断
}

问题：

• 任何一个失败，你都不知道是哪个功能出了问题
• 无法单独运行某个子场景

• 难以维护
  ✅ 正确做法：拆成三个独立测试

  [Fact] public void Add_ShouldReturnSumOfTwoNumbers() { ... }
  [Fact] public void Multiply_ShouldReturnProductOfTwoNumbers() { ... }
  [Fact] public void IsPositive_ShouldReturnTrueForPositiveNumber() { ... }

避免测试中的“魔法数字”和硬编码**

❌ 不好的写法：

Assert.Equal(12345, service.CalculateTotal());

✅ 更好的写法：

const int expectedTotal = 12345;
var result = service.CalculateTotal();
Assert.Equal(expectedTotal, result);

测试数据：善用 [Theory] + [InlineData] 做参数化测试

当你需要测试多个输入输出组合时，别写 10 个重复的 [Fact]！

✅ 示例：测试加法多种情况

[Theory]
[InlineData(1, 2, 3)]
[InlineData(-1, 1, 0)]
[InlineData(0, 0, 0)]
[InlineData(999, 1, 1000)]
public void Add_ShouldReturnCorrectSum(int a, int b, int expected)
{
    var calc = new Calculator();
    var result = calc.Add(a, b);
    Assert.Equal(expected, result);
}

✅ 优势：

• 代码复用
• 自动显示每个用例的名称（VS测试资源管理器中会列出每组）
• 新增用例只需加一行，不改结构

✅ 六、异常测试：一定要断言异常类型 + 消息（如果重要）

[Fact]
public void Divide_WhenDivisorIsZero_ThrowsArgumentExceptionWithMessage()
{
    var calc = new Calculator();

    var ex = Assert.Throws<ArgumentException>(() => 
        calc.Divide(10, 0));

    // ✅ 不仅要抛异常，还要确保错误信息正确
    Assert.Equal("除数不能为零", ex.Message);
}

测试不应依赖外部环境（数据库、文件、网络）

单元测试 = 单元测试。意思是：隔离、快速、可重复。

❌ 错误示范：

[Fact]
public void GetUserFromDatabase_ReturnsValidUser()
{
    var repo = new UserRepository(); // 实际连了 SQL Server
    var user = repo.GetUserById(1); // 依赖真实数据库
    Assert.NotNull(user);
}

👉 问题：

• 慢（数据库连接耗时）
• 不稳定（网络断了？数据被删了？）
• 无法 CI 自动运行

✅ 正确做法：使用 Mock（模拟）

[Fact]
public void GetUserById_WhenIdExists_ReturnsUser()
{
    // Arrange
    var mockRepo = new Mock<IUserRepository>();
    mockRepo.Setup(r => r.GetUserById(1))
            .Returns(new User { Id = 1, Name = "Alice" });

    var service = new UserService(mockRepo.Object);

    // Act
    var user = service.GetUserById(1);

    // Assert
    Assert.NotNull(user);
    Assert.Equal("Alice", user.Name);
}

✅ 使用 Moq 库（NuGet 包：Moq）
✅ 你的测试只关心“接口契约”，不关心实现细节
✅ 测试速度从秒级 → 毫秒级

💡 一句话记住：单元测试不碰磁盘、不联网、不读配置文件、不启动服务

测试代码也要整洁：DRY & KISS

测试代码也是代码！它也需要：

测试即文档（Documentation by Example）

你的测试，就是最真实的“使用说明书”。

[Fact]
public void CalculateDiscount_WhenUserIsPremiumAndHasMoreThan10Orders_Returns20Percent()
{
    var user = new User { IsPremium = true, OrderCount = 15 };
    var discount = service.CalculateDiscount(user);
    Assert.Equal(0.20m, discount);
}

总结：单元测试十项黄金规范（可打印贴墙上）

• 每个测试只做一件事（单一职责）
• 使用 AAA 模式，结构清晰
• 命名格式：MethodName_State_ExpectedBehavior
• 用 [Theory] + [InlineData] 替代重复测试
• 测试异常时，同时断言类型和消息
• 绝不依赖外部资源（数据库、文件、网络）
• 使用 Moq 模拟依赖，保证隔离性
• 测试代码也要整洁、可读、无重复
• 覆盖率不是目标，有意义的覆盖才是
• 测试是最好的文档 —— 让别人读懂你的意图

这篇文章有通义千问的一份功劳

本文由 jxxxy 创作，采用 知识共享署名4.0 国际许可协议进行许可。
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。