第230讲聚焦Python测试框架底层机制：深入剖析pytest收集阶段对函数/方法类型的严格判定逻辑、unittest.TestLoader的三路径解析规则，以及mock.patch基于对象绑定而非字符串匹配的本质。
这门课不是讲怎么写测试用例的入门课，而是直奔 Python 测试系统底层机制去的——如果你已经会用 unittest 或 pytest 写测试，但遇到 ImportError 找不到模块、pytest.mark.parametrize 参数没生效、或 CI 上测试顺序突然影响结果，那第 230 讲真正有用的部分，就藏在对 _pytest.python.PyCollector 和 unittest.loader.TestLoader._find_tests 的行为拆解里。
为什么 pytest 有时跳过测试函数，有时又报 not a function
根本原因在于 pytest 的收集阶段（collection phase）对对象类型的判定逻辑比表面看到的严格得多。它不只看函数名是否以 test_ 开头，还会检查：
def test_foo():
pass
class TestBar:
def test_baz(self):
pass
前者是 function 类型，后者是 instancemethod，但 pytest 还会进一步判断该方法是否属于一个合法的测试类（即是否继承自 object 且未被 @staticmethod 修饰）。常见陷阱包括：
- 在测试类里写了
@staticmethod的test_方法 → pytest 忽略它，不报错也不执行 - 把测试函数定义在
if False:块里 → 字节码中该函数仍存在，但inspect.getsource()失败，pytest 收集时抛IOError - 用
exec()动态生成测试函数 → 缺少__file__属性，pytest 默认跳过
unittest.TestLoader.loadTestsFromName() 的路径解析规则
这个方法看似简单，实则暗含三套并行路径解析逻辑：模块路径、包路径、可调用对象路径。传入字符串 "myapp.tests.test_auth.TestLogin.test_valid" 时，它会按顺序尝试：
- 先尝试导入
myapp.tests.test_auth模块，再从模块中取TestLogin类，再取其test_valid方法 - 如果导入失败（比如
myapp不在sys.path），但当前目录下有myapp/文件夹且含__init__.py，它会临时插入当前路径到sys.path[0]再试一次 - 若仍失败，且字符串含冒号（如
"test_auth.py::TestLogin::test_valid"），则切换为文件级解析模式，此时不依赖 Python 导入机制，而是用ast解析源码找类和方法定义
这意味着：CI 环境中若未正确设置 PYTHONPATH，但测试命令用了 :: 语法，可能“碰巧”通过；本地开发却因路径优先级不同而失败。
mock.patch 作用域失效的真实原因
mock.patch 不是靠“名字字符串”匹配来打补丁的，而是靠运行时对象绑定（object binding）。以下写法必然失效：
@mock.patch("requests.get")
def test_api_call(mock_get):
mock_get.return_value.status_code = 200
api.fetch_data() # 调用的是 requests.get，但 patch 生效了吗？问题出在：如果 api.py 里写的是 from requests import get，那么实际调用的是 api.get，而 patch 的是 requests.get —— 二者在内存中是两个不同对象。必须 patch “被测试代码**导入并使用的位置**”，例如：@mock.patch("api.get") # ✅ 不是 "requests.get"另一个常见错误是 patch 了类方法但忘了 self 参数占位，导致 mock 返回值被当成 self 传给下个方法，引发 TypeError。
真正卡住人的，往往不是不会写 assert，而是搞不清测试框架在哪一刻、以什么方式、根据什么规则把你的代码变成可执行的测试项。第 230 讲的价值，不在“教你怎么测”，而在告诉你：当测试行为和预期不符时，该去翻哪一行 CPython 源码、该在哪个 hook 点加 breakpoint()、以及为什么改一个 __all__ 就能让整个测试包消失。
