应使用@functools.wraps(func)修饰装饰器内层wrapper函数，确保__name__、__doc__等元数据正确继承，使pytest能正常识别测试函数名并收集用例。
装饰器导致测试函数名丢失，pytest 无法识别怎么办？
pytest 默认通过函数名匹配测试用例，但装饰器（尤其是未使用 @functools.wraps 的自定义装饰器）会覆盖原函数的 <strong>name</strong>、<strong>doc</strong> 等属性，导致 pytest 报错 collected 0 items 或找不到测试函数。
- 确保所有自定义装饰器内部调用
functools.wraps(func)，这是最根本的修复方式 - 若无法修改装饰器源码（如第三方库装饰器），可在测试文件中临时“解除”装饰：用
func.<strong>wrapped</strong>访问被装饰前的原始函数（仅适用于标准@wraps实现的装饰器） - 避免在测试函数上直接套业务装饰器（比如鉴权
@require_role），否则测试会因缺少上下文环境而失败
from functools import wraps <p>def my_decorator(func): @wraps(func) # 必须加这一行！ def wrapper(*args, *<em>kwargs): return func(</em>args, **kwargs) return wrapper</p>
测试带参数化装饰器（如 @cache.memoize(60)）时缓存干扰怎么办？
缓存类装饰器会让函数结果复用，导致多次测试断言拿到相同返回值，掩盖逻辑错误或状态变更问题。
- 在每个测试用例开始前手动清空缓存：
your_func.cache_clear()（适用于functools.lru_cache或 Flask-Caching 的.memoize） - 使用
pytest.fixture在scope="function"级别自动清理，避免遗漏 - 不要依赖装饰器自带的“过期时间”来规避问题——测试运行快，60 秒缓存几乎永不失效
例如：
import pytest <p>@pytest.fixture def clear_cache(): your_business_func.cache_clear() yield your_business_func.cache_clear()</p>
业务函数用了 @staticmethod 或 @classmethod，但测试里调用报 TypeError: ... missing 1 required positional argument
这类装饰器不改变函数签名语义，但容易在测试中误用：把方法当普通函数调，忘了实例或类上下文。
立即学习“Python免费学习笔记（深入）”；
-
@staticmethod函数可直接调用，无需实例，但必须确保调用时参数数量与定义一致 -
@classmethod第一个参数是cls，pytest 中若直接写MyClass.my_method()是合法的；但若写成my_method()（没加类前缀），就会少传cls - 更稳妥的做法：统一用类名显式调用，避免和普通函数混淆
常见错误写法：
# ❌ 错误：当成普通函数调用，但其实是 classmethod test_result = my_class_method() # 缺少 cls <h1>✅ 正确</h1><p>test_result = MyClass.my_class_method()</p>
如何验证装饰器本身的行为（比如日志是否记录、权限是否拦截）？
不能只测业务逻辑，还得确认装饰器按预期工作——比如 @log_execution 是否真打了日志，@auth_required 是否在无 token 时抛出 401。
- 用
unittest.mock.patch替换装饰器内部依赖（如日志器、数据库连接、HTTP 客户端） - 对拦截型装饰器，构造非法输入（如空 token、越权用户），检查是否抛出预期异常（
with pytest.raises(AuthError)） - 注意：不要 patch 装饰器函数本身（如
@patch('mymodule.require_auth')），而是 patch 它调用的底层判断逻辑（如check_permission），否则测试失去意义
关键点：装饰器的副作用（日志、缓存、鉴权）必须被隔离验证，而不是假设“只要函数跑通，装饰器就 ok”。
真实项目里最容易漏掉的是 <strong>wrapped</strong> 的可用性判断和 cache_clear() 的调用时机——这两个点不报错，但会让测试结果不可靠。
