断言表达式：布尔表达式、复合条件、断言与逻辑运算符
断言表达式，说白了就是你要检查的那个条件。它到底长什么样？能有多复杂？今天我们就来掰扯清楚。
布尔表达式：最基础的断言
布尔表达式，就是结果只有 True 或 False 的表达式。这是断言最核心的原料。
举个例子：
assert result == expected
assert value > 0
assert status_code == 200这些都是一条简单的布尔表达式。我刚开始写断言时，觉得这太简单了，没什么好说的。直到有一次，我写了个 assert result = expected——注意，我用了单等号！结果变成了赋值操作，永远返回 True，bug 就这么溜过去了。
⚠️ 注意： 断言里一定要用
==（比较运算符），别写成 =（赋值运算符）。这个坑我踩过，你最好别踩。
复合条件：多个条件一起判断
实际项目中，一个断言往往要检查多个条件。比如验证一个用户信息：
assert user.name == "张三" and user.age > 18 and user.status == "active"这就是复合条件。它把多个布尔表达式用逻辑运算符连起来，形成一个整体。
我个人习惯把复合条件拆开写，这样报错时能一眼看出是哪个条件失败了：
assert user.name == "张三", f"名字不对，实际是 {user.name}"
assert user.age > 18, f"年龄不够，实际是 {user.age}"
assert user.status == "active", f"状态不对，实际是 {user.status}"你想想看，如果写成一行，报错信息只会告诉你 AssertionError，你根本不知道是名字、年龄还是状态出了问题。拆开写，每条断言都有自己的错误信息，调试效率高多了。
断言与逻辑运算符
逻辑运算符有三种：and、or、not。它们可以组合出各种复杂的断言条件。
| 运算符 | 含义 | 示例 |
|---|---|---|
and |
且（所有条件都为真） | a > 0 and b < 10 |
or |
或（至少一个条件为真） | status == "ok" or retry_count < 3 |
not |
非（取反） | not error_flag |
我曾经遇到过一个场景：接口返回的数据，要么有 data 字段，要么有 error 字段，但不能两个都有。我当时写的断言是：
assert (response.get("data") is not None) != (response.get("error") is not None)嗯，这里用了异或的逻辑——两个条件不能同时为真，也不能同时为假。虽然写法有点绕，但确实管用。
💡 小技巧： 复杂逻辑条件建议加括号，明确运算优先级。比如
assert (a > 0) and (b < 10 or c == 5)，括号让代码可读性提升一大截。
知识体系结构图
下面这张图，帮你理清断言表达式的核心逻辑：
实际项目中的经验
我记得有一次，测试一个支付接口，需要验证：
- 支付金额必须大于 0
- 用户余额必须足够
- 支付状态必须是 "pending" 或 "processing"
- 不能同时有退款标记
我当时写了一个复合断言：
assert amount > 0, f"金额必须大于0，实际是 {amount}"
assert balance >= amount, f"余额不足，余额 {balance}，需要 {amount}"
assert status in ("pending", "processing"), f"状态异常：{status}"
assert not refund_flag, "不能有退款标记"你看，每个条件都拆开了，而且都带了明确的错误信息。这样一旦断言失败，我立刻知道是哪个环节出了问题。
🔑 核心要点：
- 布尔表达式是断言的基础，结果只有 True/False
- 复合条件用 and/or/not 组合多个条件
- 复杂断言建议拆开写，每条带错误信息
- 逻辑运算符注意优先级，多用括号
说白了，断言表达式就是把你脑子里的检查逻辑，翻译成代码能理解的条件。写得好，bug 无处遁形；写得不好，断言形同虚设。
可可精品资料库