Mock测试【免费下载链接】motoA library that allows you to easily mock out tests based on AWS infrastructure.项目地址https://gitcode.com/gh_mirrors/mo/moto点击查看免费下载Moto 是一个用于模拟 AWS 基础设施的 Python 测试库社区贡献者通过新增或改进各 AWS 服务的 mock 行为来推动其发展。本文以仓库 docs/docs/contributing/checklist.rst 中的 PR 检查清单为核心骨架结合仓库内的构建脚本、开发文档与测试规范系统讲解在 Moto 上提交高质量 PR 前必须完成的四项检查、对应的工具链用法以及中途卡壳时的求助路径。读完本文你将能按照官方标准跑通写功能 → 过 lint → 补测试 → 全量测试通过的完整贡献流程。PR 检查清单四项必选项官方在 PR Checklist 中定义了开 PR 前的四项检查缺一不可功能已实现Feature is addedLinter 检查通过The linter is happy测试已补充Tests are added全部测试通过包括新老用例All tests pass, existing and new这四项对应 Moto 仓库中一套明确的自动化工具链功能开发靠scripts/scaffold.py脚手架、代码风格靠 ruff mypy、测试执行靠 pytest。下面逐一展开。检查项一功能已实现用脚手架脚本生成服务与功能骨架Moto 为新增一个服务和给已有服务加新功能提供了半自动脚手架。开发者文档 New Features 说明其原理脚本通过查询给定boto3方法的 API 规范自动生成 mock 所需的模板代码减轻大量重复劳动。运行方式export AWS_DEFAULT_REGIONus-east-2 python scripts/scaffold.py脚本基于click模块提供交互式自动补全用 Tab 自动补全服务名用上下方向键在下拉列表中切换回车确认。一次典型的交互过程如下$ python scripts/scaffold.py Select service: codedeploy Current Implementation Status [ ] add_tags_to_on_premises_instances ... [ ] create_deployment ... [ ] update_deployment_group Select Operation: create_deployment选择后脚本会生成服务目录骨架并插入方法桩代码Initializing service codedeploy creating moto/codedeploy creating moto/codedeploy/models.py creating moto/codedeploy/exceptions.py creating moto/codedeploy/__init__.py creating moto/codedeploy/responses.py creating moto/codedeploy/urls.py creating tests/test_codedeploy creating tests/test_codedeploy/test_server.py creating tests/test_codedeploy/test_codedeploy.py inserting code moto/codedeploy/responses.py inserting code moto/codedeploy/models.py每个 AWS 服务的 mock 都遵循统一分层urls.pyURL 路由→responses.pyHTTP 请求响应层→models.py业务状态存储层→exceptions.py自定义异常对应目录结构可参见仓库中的 moto/s3、moto/ec2 等既有服务。开发完成后的收尾脚本脚手架提示开发完成后还有两个收尾步骤运行scripts/implementation_coverage.py自动更新全量支持服务清单生成 IMPLEMENTATION_COVERAGE.md运行scripts/update_backend_index.py因为 MotoServer 为了性能会对所有需要拦截的 AWS URL 建索引凡是新增或替换了{service}/urls.py中的路由都必须重跑该脚本刷新索引否则 ServerMode 下会拦截不到新接口。检查项二Linter 检查通过为什么必须固定 ruff 版本仓库在 requirements-dev.txt 中固定了ruff0.14.10而 FAQ for Developers 特别强调不同版本的 ruff 会产生不同的检查结果CI 使用的正是requirements-dev.txt里锁定的版本。因此本地必须安装同一版本否则可能出现本地 lint 通过、CI 却失败的尴尬局面。贡献指南 CONTRIBUTING.md 同样提醒要保证正确的 ruff 版本。一键 lint 与一键格式化仓库根目录的 Makefile 封装了标准命令make lint该目标依次执行ruff check moto tests ruff format --check moto tests mypy --install-types --non-interactive即同时校验 ruff 的静态检查、格式检查与 mypy 类型检查。如果代码不符合规范用make format自动修复make format其内部实现为ruff format moto/ tests/ ruff check --fix moto/ tests/按服务单独验证Development Installation 给出了针对单个服务以 s3 为例的完整验证命令适合开发迭代期快速反馈ruff check moto/s3 tests/test_s3 ruff format --check moto/s3 tests/test_s3 mypy pytest -sv tests/test_s3若 ruff 检查失败运行make format自动格式化有问题的文件即可。mypy 的严格配置mypy 的严格程度在 setup.cfg 的[mypy]段中定义开启disallow_untyped_defs禁止无类型注解的函数定义、strict_optional、strict_equality等严格选项检查范围覆盖moto全部代码及tests/test_core、tests/test_batch_simple、tests/test_iotdata。类型检查范围刻意排除了moto/stepfunctions/parser。这意味着新增代码基本都要带完整的类型注解写代码时就要注意标注参数与返回值类型。检查项三测试已补充一个测试只验证一个功能点开发文档 Writing tests 明确了 Moto 的测试风格一条测试只验证一个功能/方法例如create_resource()一条、update_resource()另一条避免把多个断言堆进一个大测试里。负向测试的标准格式针对异常场景负向测试官方推荐统一写法用pytest.raises捕获ClientError并逐一断言错误码与错误消息with pytest.raises(botocore.exceptions.ClientError) as exc: client.failing_call(..) err exc.value.response[Error] # 使用 pytest 的 assert 方法 assert err[Code] .. assert err[Message] ..这种写法是确保 Moto 正确处理异常的最佳方式。ServerMode 测试CI 会对全部测试跑两遍一遍普通模式一遍 ServerModeMoto 以独立 Flask 服务器运行。本地验证 ServerMode 是否通过的方法python moto/server.py TEST_SERVER_MODEtrue pytest -sv tests/test_service/..ServerMode 下每个 boto3 client/resource 都会被拦截并自动附加endpoint_urlhttp://localhost:5000从而用同一套测试同时验证装饰器模式与 ServerMode 行为一致。详情可参考 FAQ for Developers 对三类测试的说明decorator tests针对内存 Moto 实例的普通单元测试ServerMode tests同一套测试改为跑在外部 MotoServer 实例上server tests位于test_server.py低层测试在内存中启动 MotoServer 后直接对服务器发 HTTP 请求用于验证 HTTP 头、精确的请求/响应格式等。并行测试的注意事项为加速 CIawslambda、batch、ec2、sqs等服务的测试会并行执行见 Makefile 中TEST_SERVER_MODE分支与-n 4 --dist loadscope的 pytest 并行参数。并行意味着函数名、队列名等资源名必须保证唯一避免跨测试冲突describe_reservations()/list_queues()等列举类调用可能返回其他测试创建的资源断言时要容忍这种污染。检查项四全部测试通过新老用例一键全量验证安装依赖与运行全量测试的标准入口在 Makefile 与 Development Installation 中make init make test其中make init执行pip install -e .可编辑安装与pip install -r requirements-dev.txtmake test会先跑 lint 再跑test-only。首次运行全量测试可能较慢——尤其是 Lambda 相关用例需要先下载 Docker 镜像。test-only 目标的分组策略make test-only展示了仓库的测试编排思路用--ignore排除 batch、dynamodb、ec2、s3、sqs 等需要并行的测试目录单独运行tests/test_xray因 AWS X-Ray SDK 的已知 issue不能开 coverage用-m requires_clean_slate标记单独跑需要干净环境的用例对剩余并行用例用-n 4 --dist loadscope加速并设置MOTO_CALL_RESET_APIfalse避免并行时相互重置状态。pytest 的 marker 定义同样在 setup.cfg 中network需要网络连接requires_docker需要运行中的 Dockeraws_verified已对 AWS 验证可对真实 AWS 运行requires_clean_slate需要干净环境不能并行。Docker 依赖须知AWSLambda 与 Batch 服务通过 Docker 执行提交的代码因此本地跑相关测试前需确保 Docker 已安装并可用参见 FAQ for Developers。首次运行需要下载对应 Docker 镜像这通常是最耗时的一步。卡壳了怎么办允许半成品 PR官方对贡献者非常宽容。PR Checklist 明确说明四项检查无法全部通过照样可以开 PR——让其他人看到代码反而更容易帮你定位问题开发到一半没时间收尾也可以先开 PR——别人可以在你的成果上继续完成功能。对于还没完全就绪的 PR官方建议打上needs-help标签needs-help-label表明状态。这不影响 CI 或评审只用于向社区传递需要帮忙的信号。不确定做什么 / 遇到问题时的求助路径如果还不确定该实现什么功能或者想就实现思路征求建议官方建议直接在 GitHub 上开一个 issue仓库根目录也提供了 ISSUE_TEMPLATE.md 模板。开发中遇到的具体报错可以参考 FAQ for Developers 中的几个高频场景场景一scaffold 脚本报ModuleNotFoundError: No module named moto.kafka通常是因为先执行了pip install .非可编辑安装再运行scripts/scaffold.py。解决方式是把 Moto 卸载后改为可编辑安装pip uninstall moto pip install -e .场景二ServerMode 下测试失败检查{service}/urls.py中的 URL 路径是否齐全正确确认之后已运行scripts/update_backend_index.py让 MotoServer 感知到路由变化。场景三ZSH 下安装报zsh: no matches foundZSH 要求整个模块名加引号例如pip install moto[ssm]结语Moto 的 PR 检查清单虽然只有四行背后却是一整套可落地的工程规范脚手架生成功能骨架、固定版本 ruff mypy 严格模式守质量、按一个测试一个功能点的标准写用例、make lint/make test/make format一键完成全部质量门禁。对照 checklist.rst 逐项勾选再配合 CONTRIBUTING.md、Makefile 与 installation.rst 中的命令任何人都能稳定地产出符合 Moto 社区标准的贡献即使中途受阻也完全可以借助半成品 PR 与needs-help标签把工作接力给社区。赞分享Mock测试【免费下载链接】motoA library that allows you to easily mock out tests based on AWS infrastructure.项目地址https://gitcode.com/gh_mirrors/mo/moto点击查看免费下载相关推荐Playball社区贡献指南提交PR前的检查清单Playball社区贡献指南提交PR前的检查清单 你还在为提交PR后反复修改而烦恼本文将提供一份全面的检查清单帮助你确保贡献质量提高PR合并效率。读完本Figma-Context-MCP社区贡献指南提交PR前的检查清单Figma Context MCP社区贡献指南提交PR前的检查清单 前言为什么需要贡献检查清单 作为Figma Context MCPMCP ServeAI 应用MCP 服务RAWGraphs-app开源贡献指南提交PR前的代码检查清单RAWGraphs app开源贡献指南提交PR前的代码检查清单 贡献准备 环境配置 1. 克隆仓库 git clone https://gitcode.co数据可视化前端上一篇PyMe一站式开发工具完全指南下一篇深度解析YOLOv8 AI自瞄系统从入门到精通实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Moto 贡献指南：PR 提交前的完整检查清单与质量保障流程
Mock测试【免费下载链接】motoA library that allows you to easily mock out tests based on AWS infrastructure.项目地址https://gitcode.com/gh_mirrors/mo/moto点击查看免费下载Moto 是一个用于模拟 AWS 基础设施的 Python 测试库社区贡献者通过新增或改进各 AWS 服务的 mock 行为来推动其发展。本文以仓库 docs/docs/contributing/checklist.rst 中的 PR 检查清单为核心骨架结合仓库内的构建脚本、开发文档与测试规范系统讲解在 Moto 上提交高质量 PR 前必须完成的四项检查、对应的工具链用法以及中途卡壳时的求助路径。读完本文你将能按照官方标准跑通写功能 → 过 lint → 补测试 → 全量测试通过的完整贡献流程。PR 检查清单四项必选项官方在 PR Checklist 中定义了开 PR 前的四项检查缺一不可功能已实现Feature is addedLinter 检查通过The linter is happy测试已补充Tests are added全部测试通过包括新老用例All tests pass, existing and new这四项对应 Moto 仓库中一套明确的自动化工具链功能开发靠scripts/scaffold.py脚手架、代码风格靠 ruff mypy、测试执行靠 pytest。下面逐一展开。检查项一功能已实现用脚手架脚本生成服务与功能骨架Moto 为新增一个服务和给已有服务加新功能提供了半自动脚手架。开发者文档 New Features 说明其原理脚本通过查询给定boto3方法的 API 规范自动生成 mock 所需的模板代码减轻大量重复劳动。运行方式export AWS_DEFAULT_REGIONus-east-2 python scripts/scaffold.py脚本基于click模块提供交互式自动补全用 Tab 自动补全服务名用上下方向键在下拉列表中切换回车确认。一次典型的交互过程如下$ python scripts/scaffold.py Select service: codedeploy Current Implementation Status [ ] add_tags_to_on_premises_instances ... [ ] create_deployment ... [ ] update_deployment_group Select Operation: create_deployment选择后脚本会生成服务目录骨架并插入方法桩代码Initializing service codedeploy creating moto/codedeploy creating moto/codedeploy/models.py creating moto/codedeploy/exceptions.py creating moto/codedeploy/__init__.py creating moto/codedeploy/responses.py creating moto/codedeploy/urls.py creating tests/test_codedeploy creating tests/test_codedeploy/test_server.py creating tests/test_codedeploy/test_codedeploy.py inserting code moto/codedeploy/responses.py inserting code moto/codedeploy/models.py每个 AWS 服务的 mock 都遵循统一分层urls.pyURL 路由→responses.pyHTTP 请求响应层→models.py业务状态存储层→exceptions.py自定义异常对应目录结构可参见仓库中的 moto/s3、moto/ec2 等既有服务。开发完成后的收尾脚本脚手架提示开发完成后还有两个收尾步骤运行scripts/implementation_coverage.py自动更新全量支持服务清单生成 IMPLEMENTATION_COVERAGE.md运行scripts/update_backend_index.py因为 MotoServer 为了性能会对所有需要拦截的 AWS URL 建索引凡是新增或替换了{service}/urls.py中的路由都必须重跑该脚本刷新索引否则 ServerMode 下会拦截不到新接口。检查项二Linter 检查通过为什么必须固定 ruff 版本仓库在 requirements-dev.txt 中固定了ruff0.14.10而 FAQ for Developers 特别强调不同版本的 ruff 会产生不同的检查结果CI 使用的正是requirements-dev.txt里锁定的版本。因此本地必须安装同一版本否则可能出现本地 lint 通过、CI 却失败的尴尬局面。贡献指南 CONTRIBUTING.md 同样提醒要保证正确的 ruff 版本。一键 lint 与一键格式化仓库根目录的 Makefile 封装了标准命令make lint该目标依次执行ruff check moto tests ruff format --check moto tests mypy --install-types --non-interactive即同时校验 ruff 的静态检查、格式检查与 mypy 类型检查。如果代码不符合规范用make format自动修复make format其内部实现为ruff format moto/ tests/ ruff check --fix moto/ tests/按服务单独验证Development Installation 给出了针对单个服务以 s3 为例的完整验证命令适合开发迭代期快速反馈ruff check moto/s3 tests/test_s3 ruff format --check moto/s3 tests/test_s3 mypy pytest -sv tests/test_s3若 ruff 检查失败运行make format自动格式化有问题的文件即可。mypy 的严格配置mypy 的严格程度在 setup.cfg 的[mypy]段中定义开启disallow_untyped_defs禁止无类型注解的函数定义、strict_optional、strict_equality等严格选项检查范围覆盖moto全部代码及tests/test_core、tests/test_batch_simple、tests/test_iotdata。类型检查范围刻意排除了moto/stepfunctions/parser。这意味着新增代码基本都要带完整的类型注解写代码时就要注意标注参数与返回值类型。检查项三测试已补充一个测试只验证一个功能点开发文档 Writing tests 明确了 Moto 的测试风格一条测试只验证一个功能/方法例如create_resource()一条、update_resource()另一条避免把多个断言堆进一个大测试里。负向测试的标准格式针对异常场景负向测试官方推荐统一写法用pytest.raises捕获ClientError并逐一断言错误码与错误消息with pytest.raises(botocore.exceptions.ClientError) as exc: client.failing_call(..) err exc.value.response[Error] # 使用 pytest 的 assert 方法 assert err[Code] .. assert err[Message] ..这种写法是确保 Moto 正确处理异常的最佳方式。ServerMode 测试CI 会对全部测试跑两遍一遍普通模式一遍 ServerModeMoto 以独立 Flask 服务器运行。本地验证 ServerMode 是否通过的方法python moto/server.py TEST_SERVER_MODEtrue pytest -sv tests/test_service/..ServerMode 下每个 boto3 client/resource 都会被拦截并自动附加endpoint_urlhttp://localhost:5000从而用同一套测试同时验证装饰器模式与 ServerMode 行为一致。详情可参考 FAQ for Developers 对三类测试的说明decorator tests针对内存 Moto 实例的普通单元测试ServerMode tests同一套测试改为跑在外部 MotoServer 实例上server tests位于test_server.py低层测试在内存中启动 MotoServer 后直接对服务器发 HTTP 请求用于验证 HTTP 头、精确的请求/响应格式等。并行测试的注意事项为加速 CIawslambda、batch、ec2、sqs等服务的测试会并行执行见 Makefile 中TEST_SERVER_MODE分支与-n 4 --dist loadscope的 pytest 并行参数。并行意味着函数名、队列名等资源名必须保证唯一避免跨测试冲突describe_reservations()/list_queues()等列举类调用可能返回其他测试创建的资源断言时要容忍这种污染。检查项四全部测试通过新老用例一键全量验证安装依赖与运行全量测试的标准入口在 Makefile 与 Development Installation 中make init make test其中make init执行pip install -e .可编辑安装与pip install -r requirements-dev.txtmake test会先跑 lint 再跑test-only。首次运行全量测试可能较慢——尤其是 Lambda 相关用例需要先下载 Docker 镜像。test-only 目标的分组策略make test-only展示了仓库的测试编排思路用--ignore排除 batch、dynamodb、ec2、s3、sqs 等需要并行的测试目录单独运行tests/test_xray因 AWS X-Ray SDK 的已知 issue不能开 coverage用-m requires_clean_slate标记单独跑需要干净环境的用例对剩余并行用例用-n 4 --dist loadscope加速并设置MOTO_CALL_RESET_APIfalse避免并行时相互重置状态。pytest 的 marker 定义同样在 setup.cfg 中network需要网络连接requires_docker需要运行中的 Dockeraws_verified已对 AWS 验证可对真实 AWS 运行requires_clean_slate需要干净环境不能并行。Docker 依赖须知AWSLambda 与 Batch 服务通过 Docker 执行提交的代码因此本地跑相关测试前需确保 Docker 已安装并可用参见 FAQ for Developers。首次运行需要下载对应 Docker 镜像这通常是最耗时的一步。卡壳了怎么办允许半成品 PR官方对贡献者非常宽容。PR Checklist 明确说明四项检查无法全部通过照样可以开 PR——让其他人看到代码反而更容易帮你定位问题开发到一半没时间收尾也可以先开 PR——别人可以在你的成果上继续完成功能。对于还没完全就绪的 PR官方建议打上needs-help标签needs-help-label表明状态。这不影响 CI 或评审只用于向社区传递需要帮忙的信号。不确定做什么 / 遇到问题时的求助路径如果还不确定该实现什么功能或者想就实现思路征求建议官方建议直接在 GitHub 上开一个 issue仓库根目录也提供了 ISSUE_TEMPLATE.md 模板。开发中遇到的具体报错可以参考 FAQ for Developers 中的几个高频场景场景一scaffold 脚本报ModuleNotFoundError: No module named moto.kafka通常是因为先执行了pip install .非可编辑安装再运行scripts/scaffold.py。解决方式是把 Moto 卸载后改为可编辑安装pip uninstall moto pip install -e .场景二ServerMode 下测试失败检查{service}/urls.py中的 URL 路径是否齐全正确确认之后已运行scripts/update_backend_index.py让 MotoServer 感知到路由变化。场景三ZSH 下安装报zsh: no matches foundZSH 要求整个模块名加引号例如pip install moto[ssm]结语Moto 的 PR 检查清单虽然只有四行背后却是一整套可落地的工程规范脚手架生成功能骨架、固定版本 ruff mypy 严格模式守质量、按一个测试一个功能点的标准写用例、make lint/make test/make format一键完成全部质量门禁。对照 checklist.rst 逐项勾选再配合 CONTRIBUTING.md、Makefile 与 installation.rst 中的命令任何人都能稳定地产出符合 Moto 社区标准的贡献即使中途受阻也完全可以借助半成品 PR 与needs-help标签把工作接力给社区。赞分享Mock测试【免费下载链接】motoA library that allows you to easily mock out tests based on AWS infrastructure.项目地址https://gitcode.com/gh_mirrors/mo/moto点击查看免费下载相关推荐Playball社区贡献指南提交PR前的检查清单Playball社区贡献指南提交PR前的检查清单 你还在为提交PR后反复修改而烦恼本文将提供一份全面的检查清单帮助你确保贡献质量提高PR合并效率。读完本Figma-Context-MCP社区贡献指南提交PR前的检查清单Figma Context MCP社区贡献指南提交PR前的检查清单 前言为什么需要贡献检查清单 作为Figma Context MCPMCP ServeAI 应用MCP 服务RAWGraphs-app开源贡献指南提交PR前的代码检查清单RAWGraphs app开源贡献指南提交PR前的代码检查清单 贡献准备 环境配置 1. 克隆仓库 git clone https://gitcode.co数据可视化前端上一篇PyMe一站式开发工具完全指南下一篇深度解析YOLOv8 AI自瞄系统从入门到精通实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考