test_开头是硬性门槛，python 测试框架默认只识别 test_函数和 test 类；下划线命名更安全兼容；函数名应描述行为而非实现；参数化需显式指定 ids 提升可读性。
test_ 开头是硬性门槛，不是风格偏好
Python 的 unittest 和主流测试框架（如 pytest）默认只收集以 test_ 开头的函数或以 Test 开头的类。不遵守这个规则，函数写得再完整也不会被发现和执行。
常见错误现象：pytest 运行后显示 no tests ran，或者 unittest 报 ValueError: no such test，往往就是命名漏了下划线或拼错了前缀。
-
def check_user_login():→ 不会被识别 -
def test_user_login():→ ✅ 正确 -
def TestUserLogin():→ ❌ 类名必须是TestUserLogin（首字母大写，无下划线） -
class test_user_login:→ ❌ 类名必须以Test开头且首字母大写
下划线分隔比驼峰更安全，尤其在 pytest 中
虽然 testUserLogin 在 unittest 下可能勉强运行（取决于 Python 版本和加载方式），但 pytest 默认只认 test_ + 下划线分隔的命名。用驼峰会直接跳过，且不报错——这是最危险的情况：你以为测了，其实没跑。
使用场景：多人协作、CI 流水线、跨项目复用测试文件时，统一用下划线能避免因框架差异导致的“本地能过、CI 失败”问题。
立即学习 “Python 免费学习笔记（深入）”；
-
test_api_v2_returns_401_on_expired_token→ ✅ 清晰、兼容、可读 -
testApiV2Returns401OnExpiredToken→ ❌ pytest 默认忽略 -
test_api_v2_returns_401_on_expired_token.py→ 文件名也建议用下划线，避免 Windows 或旧 shell 解析异常
测试函数名要表达“行为”而非“实现”
名字里塞具体方法名（比如 test_validate_email_regex）看似准确，但一旦你把校验逻辑换成第三方库，这个测试名就立刻失真，还容易误导后续维护者去改错地方。
真正该描述的是“系统在什么条件下产生什么可观测结果”。这关系到测试的稳定性和重构友好度。
-
test_email_validation_rejects_missing_at_symbol→ ✅ 关注输入 / 输出行为 -
test_validate_email_regex→ ❌ 绑定实现细节，后续换正则为email-validator包就得改名 -
test_user_cannot_login_with_invalid_email→ ✅ 更上层，适合集成 / 端到端测试
参数化测试的命名别靠 suffix 撞大运
用 @pytest.mark.parametrize 时，很多人依赖默认生成的测试 ID（比如 test_login[admin-123]），但这些 ID 在 CI 日志里难定位、不可读，且一旦参数顺序或值变化，ID 就变，历史失败记录对不上。
性能影响不大，但可维护性断崖下跌——尤其当一个 test_login 跑 20 组参数，失败日志只说 test_login[17]，没人想数哪组是第 17。
- 加
ids参数显式命名：ids=["admin_valid", "user_expired_token", ……] - 避免用中文或空格做
ids值，某些旧版 pytest 会截断或报错 - 如果参数本身是复杂对象，
ids必须是字符串列表，长度与参数元组一致，否则抛ValueError
