为 Python 仓库生成可靠测试skills17 的 code-testing-extensions/python.md 实战指南【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills导读本指南围绕 skills17 仓库中dotnet-test插件提供的 Python 语言测试生成扩展文档 python.md 展开系统讲解在 AI 编码代理为 Python 项目生成单元测试时应当遵循的完整工作流从先调查仓库再动手的守则、测试框架与运行器探测、环境前缀检测、命令选择到 Mock 规则、常见错误处理与全绿或删除的收尾纪律。读完本文你将掌握一套可复制的 Python 测试生成方法论知道如何让新增测试与仓库既有惯例无缝衔接并理解其在多 Agent 测试生成管线Research → Plan → Implement → Fix中的具体落地方式。该扩展文档是code-testing-extensionsskill 为 Python 语言提供的专项指引供测试生成管线按需加载该 skill 与 test-analysis-extensions 一样设置了disable-model-invocation: true不进入模型可见的技能菜单而是由消费方按名加载。仓库中的 code-testing-agent 及其评测 eval.yaml 是验证这些规则的直接场景评测中大量 Python 任务pytest 多模块套件、ledger 边界扩展、slugify 单函数等都以测试必须通过、行为必须有命名测试证据、中间状态文件不可被暂存作为验收标准。规则一先调查仓库再写任何测试python.md 的第一条铁律是在编写任何测试或运行任何命令之前先发现仓库已经做了什么。这与code-testing-agent管线的 Researcher 阶段职责完全对应——code-testing-agent/SKILL.md 要求调用code-testing-generatorAgent 时把当前工作区视为权威即使它看起来稀疏、残缺或缺少跟踪文件。调查动作按顺序展开找出全部现有测试文件——宽泛搜索test_*.py、*_test.py、*.uts、test/*.sh或任何其他测试格式不要默认就是 pytest识别测试框架与运行器——按以下顺序检查pyproject.toml的[tool.pytest.ini_options]下的testpathspytest.inisetup.cfg的[tool:pytest]tox.ini的[testenv]下的commandsMakefile、noxfile.py、conftest.py的位置项目专属运行器如 Django 的runtests.py、manage.py test或DJANGO_SETTINGS_MODULE确定活跃测试布局——记录现有测试所在的目录、工作目录和 fixture 作用域。有些仓库使用非常规布局例如 Ansible 风格的test/units/通读现有测试——逐字复制其风格文件格式、导入方式、fixture、断言模式、辅助工具、setup/teardown 约定确定包布局——从现有代码推断导入路径而不是靠猜。使用仓库已经在用的框架与约定。如果仓库使用自定义测试框架自定义文件格式、自定义运行器、领域专用测试工具就完整采纳它——不要在其上叠加 pytest。只有当仓库完全没有测试时才引入 pytest。绝不允许以失败或报错的测试收尾。完成前必须运行完整的全新测试套件。如果一个测试在合理次数的尝试后仍无法通过就删除它。一个全部通过的小套件严格优于一个带任何失败的大套件——只要有一个测试失败整个套件就可能得零分。从简单处开始锁定覆盖率。先为纯函数、校验分支、序列化器、小型辅助函数和确定性错误路径编写高确定性的测试再尝试 async 视图、模板、会话、网络路径或集成密集型代码。从源码结构看这条从简单到复杂的策略直接映射到评测中的验收逻辑code-testing-agent的评测激励tests/dotnet-test/code-testing-agent/eval.yaml里Python 任务总是先要求覆盖空输入、边界、校验错误等确定性行为再进入协作对象交互且 rubric 明确写着以有意义、非冗余的用例评估套件质量而非奖励更高的原始测试数量。环境检测用前缀对齐仓库的真实运行环境检测锁文件/配置中声明的运行器并以此给所有命令加前缀指示器前缀poetry.lock/pyproject.toml中的[tool.poetry]poetry runpdm.lock/pyproject.toml中的[tool.pdm]pdm runuv.lock/pyproject.toml中的[tool.uv]uv runPipfile.lockpipenv runhatch.toml/pyproject.toml中的[tool.hatch]hatch run以上都没有python -mprefix只适用于模块执行。默认python -m前缀下prefix pytest展开为python -m pytest但脚本入口点或内联探针不能双重加前缀——python -m python manage.py …或python -m python -c …是非法写法。脚本入口点manage.py、runtests.py和python -c探针应当直接使用python运行检测到环境工具时用环境工具包裹例如poetry run python manage.py test …、uv run python -c …而不是python -m。如果存在Makefile、tox.ini或 nox 配置优先使用其中的脚本而不是裸命令。构建命令Python 没有独立构建步骤Python 没有独立的构建步骤。若配置了类型检查器则用它做校验范围命令语法检查prefix py_compile path/to/file.py类型检查prefix mypy path/to/file.py或prefix pyright path/to/file.py测试命令与仓库现有测试完全同构地运行运行新测试的方式必须与仓库运行现有测试的方式一致相同的工作目录、相同的命令包裹、相同的conftest.py作用域、相同的 settings 环境变量。选择命令前先用可复制粘贴的探针检查运行器配置Get-ChildItem -Recurse -File -Include pyproject.toml,pytest.ini,setup.cfg,tox.ini,Makefile,noxfile.py,conftest.py,runtests.py,manage.py Select-String -Path pyproject.toml,pytest.ini,setup.cfg,tox.ini -Pattern testpaths|\[tool.pytest|\[tool:pytest|commands|DJANGO_SETTINGS_MODULE -ErrorAction SilentlyContinue如果仓库使用自定义测试框架自定义文件格式、自定义运行器使用其原生命令——不要用 pytest 去包一层。例如框架命令UTscapy.uts文件prefix scapy.tools.UTscapy -f test/test_file.utsDjango 运行器脚本python runtests.py app_label.tests.test_moduleDjango 项目python manage.py test app_label.tests.test_module自定义运行器脚本make test、./run_tests.sh、tox仓库自定义脚本按 Makefile/tox/nox 中scripts.test指定的内容对于pytest项目最常见的情况使用检测到的prefix范围命令全部测试prefix pytest指定文件prefix pytest tests/test_module.py指定测试prefix pytest tests/test_module.py::TestClass::test_method关键字过滤prefix pytest -k keyword首个失败即停prefix pytest -x --tbshort注意事项优先python -m pytest而非裸pytest以确保使用正确的解释器如果项目只用unittest依赖里没有 pytest使用python -m unittest discover如果测试必须从子目录运行先Set-Location到该目录并在验证期间保持该工作目录。超越纯 pytest 的框架镜像现有测试的导入风格与调用方式做到逐字一致。Django优先仓库的运行器runtests.py、manage.py test或 tox/make target。若仓库使用pytest-django确保DJANGO_SETTINGS_MODULE与现有测试/配置要求的完全一致。python manage.py test app_label.tests.test_module$env:DJANGO_SETTINGS_MODULEproject.settings; python -m pytest tests/app/test_module.pyunittest 风格套件使用python -m unittest path.to.test_module或仓库的 discover 命令除非现有测试已经在用否则不要强制改成 pytest。子目录运行器有些仓库期望命令从tests/、test/units/或其他子目录执行以便相对导入和 fixture 生效。Lint 命令沿用仓库既有脚本优先使用仓库现有的 lint 脚本make lint、tox -e lint。否则从配置检测工具ruff.toml或[tool.ruff]→prefix ruff check --fix prefix ruff format[tool.black]→prefix black.flake8→prefix flake8项目布局与导入路径布局导入风格src/package/module.pyfrom package.module import X根目录package/module.pyfrom package.module import X根目录module.pyfrom module import X严格匹配现有测试的导入——除非现有测试在用否则不要发明src.前缀把新测试放在现有套件所在的目录这样同一个conftest.py、fixture、辅助函数和设置都能生效检查pyproject.toml的[tool.setuptools.package-dir]获取布局线索默认测试放置tests/镜像源码结构src/billing/service.py→tests/billing/test_service.py。从源码结构看src/布局的导入语义在评测中有直接验证code-testing-agent评测的 Python 多模块任务要求测试放在fixtures/python-multimodule/tests/下并从fixtures/python-multimodule/运行 pytest 通过而其 workspace-integrity 任务则要求把pythonpath [.]、testpaths [tests]见 eval.yaml 中 Python 任务的 prompt作为测试必须遵从的配置前提。重依赖与原生依赖先验证可导入性在为某个目标模块写测试之前先在与测试相同的环境和工作目录下验证它能干净导入。探针必须在与测试命令相同的环境包裹下运行poetry run、pdm run、uv run、pipenv run、hatch run这样检查结果才反映真实的测试解释器/虚拟环境——裸python可能解析到不同的环境并给出误导性的ok# 用检测到的环境工具包裹例如 poetry run python -c ... python -c import package.module; print(ok) python -c from package import module; print(ok)如果 NumPy、pandas、PyTorch、TensorFlow、cryptography 或编译扩展等重依赖/原生依赖无法在环境中导入或构建不要编写导入该失败模块的测试不要把预算花在对抗原生构建/导入失败或安装无关包上收缩范围到能干净导入的纯 Python 子模块或干脆跳过该模块的测试而不是交付跑不起来的测试见下文收尾全绿或删除。测试文件命名匹配仓库现有约定。常见模式pytest文件test_*.py或*_test.py函数test_前缀类Test前缀自定义框架使用现有测试使用的任何格式如 UTscapy 的.uts、自定义扩展名。如果要在完全没有测试的仓库中编写新测试默认采用 pytest 约定。常见错误速查表错误修复ModuleNotFoundError: No module named src从仓库使用的包名导入而不是从src导入ModuleNotFoundError: No module named X检查现有导入以确认正确的包名如需可编辑安装prefix pip install -e .ImportError: attempted relative import转换为匹配现有测试模式的绝对导入fixture X not found检查conftest.py中已有的 fixture复用它们而不是新建TypeError: missing required argument阅读完整的__init__/函数签名传入所有必需参数async def functions are not natively supported仅当pytest-asyncio已在依赖中时才使用pytest.mark.asyncio检查配置中是否有asyncio_mode autoDJANGO_SETTINGS_MODULE is undefined使用仓库的 Django 运行器或设置与现有测试相同的 settings 模块来自torch、numpy或编译扩展的ImportError避开该模块选择能干净导入的纯 Python 目标SyntaxError修复指示行处的语法Mocking 规则标准库优先精确打桩使用unittest.mock标准库——无需额外依赖在名称被查找的地方打桩而不是定义的地方patch(mypackage.module.datetime)而不是patch(datetime.datetime)使用Mock(specRealClass)来捕获属性错误async 函数使用AsyncMock优先依赖注入而非patch如果一个测试需要超过 3 个 mock将其标记为设计异味。这条在查找处打桩的规则在配套的 python-examples.md 中有完整的事故复盘测试把contoso_billing.invoice_service中自定义的_utcnow辅助函数错误地打桩成patch(datetime._utcnow, ...)报出AttributeError: module datetime does not have the attribute _utcnow修复方式是改为patch(contoso_billing.invoice_service._utcnow, ...)。同一个示例还演示了Mock(specInvoiceRepository)的价值无 spec 的Mock()会在访问时静默创建任意属性使find_by_id这样的笔误真实方法名为find直到生产代码调用时才暴露加上 spec 后拼写错误会在 setup 阶段直接抛AttributeError。依赖安装最后手段只有在调查确认缺失之后才安装包。使用检测到的前缀管理器安装命令Poetrypoetry add --group dev pytestPDMpdm add -dG test pytestuvuv add --dev pytestpippython -m pip install -e .[dev]绝不在 Poetry/PDM/uv 项目中运行裸pip install——它会绕过锁文件。收尾全绿或删除完成前用仓库的原生调用方式、在与仓库测试相同的环境包裹下poetry run、pdm run、uv run、pipenv run、hatch run运行你新增的全部测试。在不同的解释器/虚拟环境中做全绿检查可能在本地通过却在仓库实际运行器下失败# 示例选择上面发现的仓库原生命令/包裹 poetry run python -m pytest tests/path/to/new_tests.py uv run python -m unittest path.to.new_test_module poetry run python manage.py test app_label.tests.test_module如果任何新测试在合理修复尝试后仍失败或报错在完成前删除该测试。绝不为了多留几行代码而保留 skipped、xfailed、失败或收集错误collection-error的测试。最终提交的套件必须是全绿的。这条纪律与code-testing-agent的完成契约一脉相承code-testing-agent/SKILL.md 要求引用一次干净的运行而不是一次尝试——证据表背后的命令必须成功退出引用的必须是最终通过exit 0的测试摘要。评测层也直接将其固化为 grader例如 Python 多模块任务以python3 -m pytest -q的expected_exit_code: 0为硬性验收并额外 grep 验证RateWindow、percentile、slugify三类行为确实出现在测试中见 tests/dotnet-test/code-testing-agent/eval.yaml。跳过覆盖率工具不要配置或运行覆盖率工具coverage.py、pytest-cov。覆盖率由评测框架另行度量。仓库侧同样明确dotnet-test 插件的 README 指出非 .NET 语言应使用各语言原生覆盖率工具Python 即coverage.py/pytest-cov见 plugins/dotnet-test/README.md但生成测试阶段不应自行引入它们。完整实战从研究到全绿的一体化示例python.md 描述的是测试生成管线的 Python 侧规范仓库中的 python-examples.md 则给出了一条完整的端到端样例展示上述规则如何落成一个可运行的 pytest 套件研究对象一个src/布局的contoso_billing包InvoiceService依赖InvoiceRepository接口/协议无实现研究输出research.md识别 pytest 8.x、src/布局、无 lint、无构建步骤把invoice_service.py列为高优先级核心业务逻辑、仓库依赖需要 mock把纯 dataclass 的invoice.py与无实现的invoice_repository.py列为低优先级/跳过计划输出plan.md单一阶段覆盖calculate_total纯逻辑参数化、get_by_idmock 仓库、mark_as_paid状态迁移 打桩_utcnow生成的测试pytest.mark.parametrize表驱动calculate_total含 ROUND_HALF_UP 舍入Mock(specInvoiceRepository)作为 fixturepatch(contoso_billing.invoice_service._utcnow)固定时间戳pytest.raises断言ValueError/KeyError修复循环依次解决ModuleNotFoundError: No module named contoso_billing可编辑安装python -m pip install -e .[test]、错误打桩位置、无 spec 的 mock 笔误三个典型问题最终报告9 个测试全部通过Requirement | Evidence式的指标表9 创建 / 9 通过 / 0 失败并给出下一步建议如用hypothesis做属性测试。对照 python.md 的检查清单可以确认这套样例每一步都符合规范先研究仓库pyproject.toml声明 pytest、src/布局、环境检测无锁文件 →python -m前缀、按现有约定放置测试tests/镜像结构、Mock 规则Mock(spec...)、查找处打桩、全绿收尾9 passed。总结code-testing-extensions的 python.md 为 Python 测试生成划定了清晰的行为边界先调查再动手、框架随仓库、环境前缀一致、Mock 精确、收尾全绿。它与 code-testing-agent 的多 Agent 管线、python-examples.md 的端到端样例以及 eval.yaml 的评测验收相互印证构成了一套可审计、可复现的 Python 测试生成方法论。无论你是 AI Agent 的开发者、还是希望让 AI 助手为自己仓库生成高质量测试的工程师都可以按这份指南约束生成过程测试必须能跑、必须全绿、必须与仓库惯例同构、必须为每个需求提供可引用的测试证据。【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考