浮点数比较应使用 assertAlmostEqual，因二进制精度问题导致 assertEqual 易误判；整数/字符串仍用 assertEqual；需加自定义消息、用 subTest 避免中断、同步更新断言防假阳性。
断言该用 assertEqual 还是 assertAlmostEqual？
浮点数运算结果不能直接用 assertEqual 比较，因为二进制精度问题会导致看似相等的值实际不等。比如 0.1 + 0.2 在 Python 中不等于 0.3，而是 0.30000000000000004。此时若用 self.assertEqual(result, 0.3) 会直接失败。
业务上只要误差在可接受范围内（如 ±1e-6）就算符合预期，应改用 assertAlmostEqual，它默认按 7 位小数精度比较：
self.assertAlmostEqual(result, 0.3, places=6)
-
places控制小数点后位数（推荐显式指定，避免依赖默认值） - 对科学计算或金融类业务，可能需用
delta参数替代places，例如delta=1e-10更直观表达绝对误差容忍度 - 整数或字符串结果仍优先用
assertEqual，它语义清晰、报错信息更直接
如何让断言失败时快速定位业务逻辑问题？
默认的 assert 错误信息只显示「Expected X, got Y」，但业务预期往往涉及上下文：比如「用户余额扣减后应不低于 0」「订单总价含税应为原价 × 1.09」。光看数值对不上，看不出是税率写错、还是四舍五入时机不对。
在断言后加自定义消息，把业务规则嵌进去：
self.assertGreaterEqual(new_balance, 0, f"余额扣减后为 {new_balance}，低于零阈值，可能未校验可用余额")
- 消息里包含变量值（用 f-string），避免手动拼接出错
- 描述「为什么这个值必须满足该条件」，而不是只说「应该等于多少」
- 避免笼统写 “业务逻辑错误”，要指向具体环节，如“未触发库存预占”“税费未按分计价”
测试多个输入组合时，怎么避免断言失败后中断执行？
用 for 循环遍历测试数据时，如果某次迭代断言失败，整个用例就终止，后续数据没机会验证——你可能漏掉一批同类问题。比如测试不同优惠券类型对满减结果的影响，第 2 种券失败了，第 3–5 种就看不到结果。
改用 subTest 将每次迭代标记为独立子测试：
for coupon_type, expected_discount in test_cases:<br> with self.subTest(coupon_type=coupon_type):<br> result = calculate_discount(order_total, coupon_type)<br> self.assertEqual(result, expected_discount)
- 即使某个
subTest失败，其余仍继续执行 - 报告中会明确标出是哪个
coupon_type出问题，不用靠 print 调试 - 注意：不是所有测试框架都支持（unittest 支持，pytest 需用
@pytest.mark.parametrize替代）
业务规则变更后，怎么防止旧断言变成「假阳性」？
断言本身不会报错，不代表它还在验证正确的事。比如业务从「运费满 99 包邮」改成「满 88 包邮」，但测试里还写着 self.assertEqual(shipping_fee, 0) 且输入是 90 元订单——现在它通过了，可实际上新规则下 90 元本不该包邮，这个断言已失效。
- 每次修改业务逻辑，必须同步审视相关断言：它是否仍对应当前规则？数值是否更新？边界条件是否调整？
- 避免在断言里硬编码魔法数字，改用常量或配置项，例如
MIN_FREE_SHIPPING = 88，让断言写成self.assertEqual(shipping_fee, 0 if order_total >= MIN_FREE_SHIPPING else 8) - 对关键规则，加一条「反向断言」强化校验，比如除了检查满 88 包邮，再加
self.assertNotEqual(0, calculate_shipping(87))确保临界值之下确实不包邮
断言不是摆设，它和业务代码一样需要主动维护；最危险的不是断言失败，而是它沉默地通过了不该通过的场景。
