unittest测试核心是断言可靠、用例可维护、失败易定位；函数名必须以test_开头，否则不被发现；优先结构化断言，setUp避免耗时操作；单测运行命令需熟记。
直接用 unittest 写自动化测试脚本，核心不是“怎么搭框架”，而是“怎么让断言可靠、用例可维护、失败能快速定位”。别先急着写 setUpClass，先确保单个测试函数跑得稳、改得清、查得准。
测试函数命名必须以 test_ 开头，否则不会被自动发现
这是 unittest 的硬性规则，不是约定。哪怕只差一个下划线（比如 Test_login 或 check_login），运行 python -m unittest 时它就彻底忽略——连报错都不会有，只会显示 “Ran 0 tests”。
- ✅ 正确：
def test_user_can_login(self): - ❌ 错误：
def login_test(self):、def TestLogin(self):、def _test_login(self): - 注意：类名不需要以
Test开头也能被识别，但函数名必须是test_*
assertEqual 和 assertIn 别乱换，类型不匹配会静默失败
比如你调用 API 返回的是字符串 "{'status': 'ok'}"，却用 self.assertEqual(resp.json(), {'status': 'ok'})，会报 AttributeError: 'str' object has no attribute 'json' ——但如果你先做了 resp.text，再用 assertIn('ok', resp.text)，就可能误判：只要响应体里有 "ok" 字符就通过，哪怕实际是 {"status": "error", "msg": "token ok expired"}。
- 优先用结构化断言：
self.assertEqual(resp.status_code, 200)、self.assertDictEqual(resp.json(), {"status": "ok"}) - 字符串断言仅用于日志/错误消息校验：
self.assertIn("Invalid token", resp.json().get('msg', '')) - 遇到 JSON 解析失败？先加
try/except或用self.assertIsInstance(resp.json(), dict)检查结构
不要在 setUp 里做耗时操作，尤其别连数据库或发真实请求
每个测试函数都会触发一次 setUp，如果里面包含登录请求、清理 DB 表、生成大文件，那 20 个用例可能跑 3 分钟，且一旦失败，你不知道是 setUp 崩了还是用例逻辑错了。
立即学习“Python免费学习笔记（深入）”；
- ✅ 推荐：
setUp只初始化轻量对象，比如self.client = APIClient()、self.data = {'username': 'test'} - ✅ 耗时操作放类外或用
@classmethod+setUpClass（注意它是类级、只执行一次、不能访问self） - ⚠️ 避免：
requests.post("https://api.example.com/login")放在setUp里——网络抖动会导致整个测试集飘红
运行单个测试函数比跑全量快得多，命令要记牢
改完一行代码就跑全部用例？太慢。定位到问题后，精准运行才是常态。
- 运行单个方法：
python -m unittest test_module.TestClass.test_user_can_login - 运行整个类：
python -m unittest test_module.TestClass - 运行模块（文件）：
python -m unittest test_module - 加
-v看详细输出：python -m unittest -v test_module.TestClass.test_user_can_login
真正卡住的往往不是语法，而是断言没覆盖边界值、mock 没打对位置、或者把测试数据写死在代码里导致多人并行时冲突。这些细节比框架结构重要得多。
