C++ 单元测试核心断言详解：EXPECT_EQ 与 ASSERT_TRUE 的区别与最佳实践

在 C++ 单元测试开发中，Google test（gtest）是应用最广泛、设计最成熟的测试框架之一。其断言机制简洁而强大，其中 EXPECT_EQ 和 ASSERT_TRUE 是开发者日常使用频率最高的两类断言——前者用于值相等性验证，后者用于布尔条件判断。然而，二者在行为语义、执行流程与错误恢复能力上存在本质差异。理解这些差异，是编写健壮、可维护、易调试测试用例的关键前提。

断言类型的基本语义差异

gtest 将断言分为两类：EXPECT_* 系列（预期型）和 ASSERT_* 系列（断言型）。这一命名并非随意：EXPECT_* 在失败时仅记录错误信息并继续执行当前测试函数；而 ASSERT_* 在失败时会立即终止当前测试函数的执行，跳过后续所有语句。

这种设计源于测试场景的实际需求：

• 当验证多个独立条件（如多个字段赋值结果）时，使用 EXPECT_* 可一次性暴露全部问题；
• 当某个条件是后续逻辑的前提（如指针非空、资源初始化成功），则必须用 ASSERT_* 避免空指针解引用等未定义行为。

EXPECT_EQ：安全比对数值与对象相等性

EXPECT_EQ(val1, val2) 是最常用的比较断言，用于验证两个表达式是否相等。它要求操作数支持 operator==，且在失败时输出清晰的左右值对比。

#include <gtest/gtest.h>
#include <string>

TEST(ComparisonTest, stringEquality) {
    std::string a = "hello";
    std::string b = "world";
    EXPECT_EQ(a.size(), 5);           // ✅ 通过：5 == 5
    EXPECT_EQ(a, "hello");            // ✅ 通过：字符串内容一致
    EXPECT_EQ(a, b);                  // ❌ 失败：输出 "Expected: a\n  Which is: 'hello'\nTo be equal to: b\n  Which is: 'world'"
}

值得注意的是，EXPECT_EQ 对自定义类型同样有效，前提是已正确定义 operator==：

struct Point {
    int x, y;
    bool operator==(const Point& other) const {
        return x == other.x && y == other.y;
    }
};

TEST(CustomTypeTest, PointEquality) {
    Point p1{3, 4};
    Point p2{3, 4};
    EXPECT_EQ(p1, p2);  // ✅ 通过：调用自定义 == 运算符
}

ASSERT_TRUE：前置条件验证的守门人

ASSERT_TRUE(condition) 用于验证布尔表达式的真值。它不进行值比对，只关心条件是否为 true。一旦为 false，测试立即中止。

TEST(PreconditionTest, SafePointerUsage) {
    int* ptr = new int(42);

    ASSERT_TRUE(ptr != nullptr);  // ✅ 通过：指针有效，继续执行
    EXPECT_EQ(*ptr, 42);          // ✅ 验证解引用结果

    delete ptr;
    ptr = nullptr;

    ASSERT_TRUE(ptr != nullptr);  // ❌ 失败：测试在此终止，下一行不会执行
    EXPECT_EQ(*ptr, 0);           // ← 此行永不运行
}

若将 ASSERT_TRUE(ptr != nullptr) 替换为 EXPECT_TRUE(ptr != nullptr)，则即使指针为空，后续 EXPECT_EQ(*ptr, 0) 仍会被执行，导致程序崩溃。因此，在涉及内存访问、文件句柄、网络连接等敏感资源前，务必使用 ASSERT_* 建立安全边界。

混合使用策略：构建分层验证逻辑

实际项目中，常需组合多种断言构建逻辑链条。例如测试一个简单计算器类：

class calculator {
public:
    int add(int a, int b) { return a + b; }
    int divide(int a, int b) {
        if (b == 0) throw std::invalid_argument("division by zero");
        return a / b;
    }
};

TEST(calculatorTest, BasicOperations) {
    calculator calc;

    // 第一层：基础功能验证（EXPECT_*，允许并行反馈）
    EXPECT_EQ(calc.add(2, 3), 5);
    EXPECT_EQ(calc.add(-1, 1), 0);

    // 第二层：异常路径前置检查（ASSERT_*，保障后续安全）
    ASSERT_NO_THROW(calc.divide(10, 2));  // 确保除法不抛异常
    EXPECT_EQ(calc.divide(10, 2), 5);

    // 第三层：边界条件验证（独立断言，互不影响）
    EXPECT_THROW(calc.divide(5, 0), std::invalid_argument);
    EXPECT_EQ(calc.add(0, 0), 0);
}

该示例体现了清晰的分层思想：先验证常规路径，再确保异常路径可控，最后独立检查边界情形。各层之间职责分明，失败时定位精准。

常见误区与规避建议

• 误用 EXPECT_TRUE(a == b) 替代 EXPECT_EQ(a, b)：前者仅报告 true/false，后者提供具体值对比，调试效率相差显著；
• *在循环中滥用 `ASSERT_**：若需验证数组每项，应优先用EXPECT_*`，避免单个失败阻断全部检查；
• 忽略自定义类型的 operator== 实现细节：若未声明为 const 或未正确处理浮点精度，EXPECT_EQ 可能行为异常。

结语：断言是测试的语法，更是设计的契约

EXPECT_EQ 与 ASSERT_TRUE 不仅是语法符号，更承载着测试作者对代码行为的明确承诺。EXPECT_* 表达“我期望这些事实同时成立”，体现测试的完整性；ASSERT_* 表达“此条件不满足则后续无意义”，体现测试的严谨性。掌握二者差异，合理搭配使用，不仅能提升测试覆盖率与可读性，更能反向促进生产代码的接口清晰性与错误防御能力。在持续集成与重构频繁的现代 C++ 工程中，一套语义准确、层次分明的断言体系，正是高质量交付最坚实的第一道防线。