@Mock、@InjectMocks 或 patch 语句的繁琐步骤，直接产出一套可运行且覆盖边界与异常路径的测试代码。然而，前提是必须正确配置环境并理解它如何“推断”你的 Mock 意图——否则生成的代码可能无法正常运行。
确保项目环境就绪并启用通义灵码
首先，启动 PyCharm（2024.2 及以上版本）或 IDEA，进入 Settings → Plugins，搜索“通义灵码”并完成安装。安装后重启 IDE，使用阿里云账号登录——【未登录将无法启用 Mock 感知能力】。请确认右下角状态栏显示“通义灵码已就绪”，否则生成的测试代码可能缺少依赖模拟逻辑。
此外，请确保项目中已包含 pytest 或 unittest 依赖。通义灵码会根据 pyproject.toml 或 requirements.txt 自动检测所使用的测试框架；如果项目尚未安装任何测试框架，它会默认生成 pytest 风格的代码——但不会自动为你安装相应的包，需要你提前手动安装。
为含外部依赖的函数一键生成带 Mock 的测试
将光标定位到目标函数名上——例如一个调用了 requests.get 和数据库 session.query() 的服务方法——右键选择 “通义灵码 → Generate Unit Test”。
通义灵码会自动扫描函数体内所有第三方调用：它能识别 HTTP 请求、数据库查询、Redis 操作、消息队列发布等，随后在生成的测试文件中添加对应的 Mock 行为。例如，如果检测到 requests.get(url)，它会在测试的 setUp 或 fixture 中注入 requests_mock.get(url, json={...})，或者使用 patch('requests.get') 并预先设置好返回值。
整个过程中，你无需手动编写任何 @patch 装饰器或构造 Mock 对象——通义灵码已基于函数签名和调用上下文自动完成了推断。例如，如果函数参数中包含 db_session: Session，它会自动生成 mock_session = MagicMock() 并注入到测试方法的参数中。
手动干预 Mock 行为的三种方法
自动生成的结果可能不完全符合你的预期——不过别担心，通义灵码提供了三种干预方式。
方法一：在待测函数上方添加注释指令。例如，在函数前空一行，写入 # @mock requests.post → return_value={"status": "ok"}。保存文件后重新触发生成，通义灵码将严格按照此规则构造 Mock 行为，而非依赖默认推断。
方法二：选中某段调用代码（例如 redis_client.set("key", value)），右键 -> “通义灵码 → Mock This Call”。它会在当前测试方法内插入一个完整的 patch 块，包含 import、start、stop 以及返回值设定，且作用域仅限该测试用例。
方法三：生成后直接编辑测试文件。在 def test_* 方法中调用 with patch("xxx.yyy") as mock_obj: 块——通义灵码生成的测试已预留好空行与缩进，你只需补充两行代码即可生效，无需调整整体结构。
验证 Mock 是否生效的三大检查点
测试生成完毕后，不要直接当作成品使用——至少按以下三步进行验证，否则上线后才发现 Mock 未生效，那就尴尬了。
第一步：运行生成的测试，观察是否出现 ConnectionRefusedError 或 OperationalError 错误。如果报错，说明某处外部调用未被 Mock 掉，返回检查函数内是否存在硬编码的 new 实例（例如 MyApiClient()），这类情况通义灵码可能无法自动识别。
第二步：在测试方法末尾临时添加一句 print(mock_requests_get.call_args_list)（变量名以实际生成为准），运行后检查输出是否为空列表——非空才表示 Mock 已真正接管了调用。
第三步：删除测试文件中所有 patch 相关代码，再次运行测试。如果此时测试失败（例如超时或连接拒绝），则反向证明原来的 Mock 有效；如果测试仍然通过，说明该依赖实际并未被函数执行路径触达，可以安全地移除对应的 Mock。
【切勿跳过第三步——很多开发者误以为生成的代码一定正确，结果上线后才发现 Mock 根本没起作用】