第1章 · 断言重用概述
说实话，做了这么多年自动化测试，我见过太多团队在回归测试里反复造轮子。每个测试用例都写一套全新的断言逻辑——结果就是代码膨胀、维护困难、一改全改。今天咱们就来聊聊断言重用这件事。为什么它值得你花时间？核心价值在哪？又有什么坑等着你？
为什么需要断言重用
回归测试里，最烦人的就是重复。你想想看，一个接口返回的字段校验，可能出现在十几个用例里。如果每个用例都写一遍 assert response['status'] == 200，哪天字段名变了，你得改到吐血。
我经历过一个项目，回归用例从 200 个涨到 800 个，断言代码膨胀了 4 倍。后来我实在受不了，抽了一个周末把公共断言提取成函数。结果呢？维护量直接砍半。说白了，断言重用就是对抗熵增——不让你的测试代码变成一团乱麻。
核心痛点： 没有重用的断言，就像每个人用自己的方言写测试——别人看不懂，自己也容易忘。
断言重用的核心价值
我个人习惯把断言重用的价值归纳为三点，你听听看：
- 减少重复劳动 —— 一次编写，多处调用。改一处，全局生效。
- 提升可读性 —— 用语义化的名字代替一堆 assert 细节。比如
assert_user_created()比五六个 assert 堆在一起清爽多了。 - 降低维护成本 —— 业务逻辑变了？只改断言函数内部，不用满世界找用例。
我记得有一次，业务方改了订单状态码，从 'SUCCESS' 变成 'FINISHED'。因为我把断言封装成了 assert_order_status，只改了一行代码，所有用例全过。要是没重用……嗯，那个周末我可能就泡汤了。
💡 我的小技巧： 断言函数命名时，尽量用业务术语，而不是技术术语。比如
assert_invoice_generated 比 assert_field_not_none 更有价值。
断言重用的挑战
好处很明显，但挑战也不小。我踩过不少坑，给你列几个典型的：
- 抽象粒度拿不准 —— 太粗了，复用场景少；太细了，跟没封装差不多。我曾经把一个断言拆成 8 个参数，结果调用时比原来还长……后来果断重构。
- 团队规范不统一 —— 有人喜欢用自定义断言，有人喜欢用框架自带的。最后代码库里有三套风格，新同事直接懵掉。
- 过度抽象导致调试困难 —— 断言函数嵌套好几层，报错时堆栈信息根本看不懂。你想想看，一个断言失败，你得翻三层函数才知道哪个字段不对。
⚠️ 避坑指南： 我曾经把断言抽象做得太“优雅”，结果定位问题花了三倍时间。后来我定了个规矩：断言函数最多嵌套两层，超过就拆。
其实断言重用不是银弹。它需要设计、需要规范、也需要团队达成共识。但一旦走上正轨，你会发现回归测试变得前所未有的轻松。嗯，下一章咱们聊聊具体的设计原则，不过今天先消化这些基础。