尧图网站建设 
Aptos MoveFlow 中的 Move 单元测试编写规范test 属性、预期失败与覆盖率基线工作流【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core本文基于 aptos-core 仓库中 MoveFlow 插件的模板文件 unit_test_rules.md 展开。该模板是 MoveFlow位于 aptos-move/flow 的 Claude Code 插件提供 MCP 服务器、插件生成器与编辑 Hook注入给 AI Agent 的 Move 单元测试语法规则与测试设计准则。读完本文你将掌握 Move 单元测试的全部核心属性#[test]、#[expected_failure]、#[test_only]及其变体用法、signer 绑定机制、常用测试工具函数以及配套的覆盖率基线baseline工作流在 MCP 工具中的底层实现。模板在 MoveFlow 中的定位unit_test_rules.md 是一个 Tera 模板片段文件以{# Move unit testing rules #}注释开头并使用{% if once(nameunit_test_rules) %} ... {% endif %}包裹保证被多个 Agent/Skill 重复 include 时只渲染一次。根据 CLAUDE.md 的说明cont/目录下的模板通过 Tera 语法组织为四类cont/agents/Agent 指令文件、cont/skills/技能定义、cont/hooks/事件 Hook 配置与cont/templates/被 include 的共享片段。该规则片段被以下文件引用最终进入move-test技能与 Agent 的提示词unit_test_ref.md单元测试参考材料通过{% include templates/unit_test_rules.md %}引入本片段并追加工具使用说明与生成测试的位置约束unit_test_tasks.md测试生成工作流的 6 个步骤被放在 Agent 提示词最前面move-test/SKILL.md 与 move-test.md分别组装 tasks ref 两部分内容。因此理解本规则片段时应把它看作AI 编写 Move 单元测试时必须遵守的语法规则 设计规范而非面向人的泛泛教程。Move 单元测试语法测试属性Test Attributes模板给出了完整的属性对照表这是编写任何 Move 单元测试的入口属性用途#[test]将函数标记为测试#[test(name addr)]测试函数中 signer 参数绑定到指定地址#[test_only]仅编译进测试产物的代码模块、函数、struct、常量均可#[expected_failure]预期会 abort 的测试任意代码#[expected_failure(abort_code N)]预期以特定 abort code 中止#[expected_failure(abort_code N, location mod)]预期在特定模块位置中止Signer 参数绑定模板强调signer 通过 test 属性绑定而不是作为函数实参传入。函数签名中声明signer参数属性中给出参数名 地址的映射// 单个 signer #[test(account 0x1)] fun test_single(account: signer) { } // 多个 signer #[test(admin admin_addr, user 0x42)] fun test_multi(admin: signer, user: signer) { } // 框架 signer用于时间戳、创建账户等 #[test(aptos_framework aptos_framework)] fun test_framework(aptos_framework: signer) { }其中admin_addr、aptos_framework是 Move 包命名地址named address的引用写法在Move.toml中定义。预期失败Expected Failures模板规定用#[expected_failure]来验证代码在特定条件下确实正确中止优先写精确的 abort code 和 location只有当失败的种类本身就是被测行为时才使用无约束的#[expected_failure]。任意 abort#[test] #[expected_failure] fun test_will_abort() { abort 1 }带 abort code必须精确匹配#[test] #[expected_failure(abort_code E_NOT_AUTHORIZED, location Self)] fun test_unauthorized() { /* should abort with E_NOT_AUTHORIZED */ }带 location错误来源在另一个模块时#[test] #[expected_failure(abort_code 26113, location extensions::table)] fun test_table_error() { /* should abort in table module */ }执行错误非 abort而是运行时失败例如算术错误溢出、除零和 vector 越界// 算术错误溢出、除零 #[test] #[expected_failure(arithmetic_error, location Self)] fun test_overflow() { let _ 255u8 1; } // Vector 越界 #[test] #[expected_failure(vector_error, minor_status 1, location Self)] fun test_out_of_bounds() { vector::borrow(vector::emptyu8(), 0); }仅限测试的代码Test-only code#[test_only]既可标注整个模块整个模块只在测试时编译也可标注普通模块中的函数// 测试专用模块整个模块只在测试时编译 #[test_only] module my_addr::test_helpers { public fun setup(): u64 { 100 } } // 普通模块中的测试专用函数 module my_addr::my_module { #[test_only] public fun init_for_testing(account: signer, value: u64) { move_to(account, MyResource { value }); } }这与 MCP 工具侧的实现相呼应package_test.rs 中构造的BuildConfig设置了test_mode: true即测试编译走独立的 test 模式构建#[test_only]代码只存在于该模式下。常用测试工具模板列出的一组常用辅助操作// 从 signer 取地址 use std::signer; let addr signer::address_of(account); // 创建账户会在链上注册 use aptos_framework::account; account::create_account_for_test(addr); // 只创建 signer 不注册轻量 let signer account::create_signer_for_test(0x123); // 检查资源是否存在 assert!(existsMyResource(addr), E_NOT_FOUND); // 初始化时间戳调用时间函数前必须执行 use aptos_framework::timestamp; timestamp::set_time_has_started_for_testing(aptos_framework); // 推进时间 timestamp::update_global_time_for_test(1000000); // 微秒 timestamp::update_global_time_for_test_secs(100); // 秒测试设计规范Test design模板给出了四条设计准则与命名约定这部分直接约束 Agent 生成测试的质量每个测试只测一种行为并用到达该行为所需的最少 setup只要可见性允许就直接调用被测函数对无法访问的私有函数通过可观察的公共行为来测或使用已有的模块内测试模式——不要为了测试而修改生产代码的可见性注释要解释所检查的行为尤其是 abort 与边界情况断言语义结果而不是断言偶发的实现细节。命名约定函数名test_function_scenario如test_transfer_insufficient_balance测试模块名module_tests。常见错误RESOURCE_ALREADY_EXISTS不要对同一资源初始化两次MISSING_DATA调用前先确保所需资源存在Signer 不匹配凡是用signer::address_of()做鉴权检查的操作必须在 test 属性中把正确的 signer 绑定到预期地址。生成测试的落位与失败诊断参考材料 unit_test_ref.md 在本规则之外补充了工作流约束新生成的测试只允许创建或扩展tests/move_flow/module_tests.move且模块需带#[test_only]标注#[test_only] module package_address::module_tests { use package_address::module; #[test(account 0x1)] /// ai-generated /// Verifies that function behavior. fun test_function_scenario(account: signer) { ... } }对失败测试的诊断分三类编译错误——修测试本身setup 或断言写错——修正生成的测试疑似生产缺陷——把复现用例移到包根目录的bugs/下并记录预期 vs 实际除非用户明确要求否则不改生产代码。整个工作流中只允许编辑tests/move_flow/与bugs/下的生成文件。配套 MCP 工具的底层实现规则片段中的用法最终由两个 MCP 工具承载实现在 package_test.rs1.move_package_test——参数为package_path与establish_baseline源码。其响应结构TestResponse包含success、baseline_established仅 baseline 模式、newly_covered源码文件路径 → 新增覆盖行号集合仅正常模式与output失败时或无基线时的提示。关键行为Baseline 模式只在测试全部通过时才把当前覆盖率存为基线save_baseline_coverage_map源码确保基线反映一次有效的测试运行包内没有任何测试时则创建一个空基线。正常模式与基线对比返回基线中未覆盖、现在已覆盖的行compute_newly_covered源码测试失败时跳过覆盖率分析因为覆盖率图可能反映的是部分执行结果。基线文件保存在会话临时目录文件名用规范化的包路径哈希命名baseline_coverage_{hash}.mvcov使./pkg与绝对路径得到同一哈希避免碰撞源码。测试执行通过run_tests调用run_move_unit_tests固定TEST_GAS_LIMIT 100_000防止死循环挂起并启用覆盖率统计compute_coverage: true源码。2.move_package_coverage——参数package_path与可选的function: module::function源码。指定函数时用make_function_line_filter按函数在源码中的行范围过滤覆盖率图缺失、或源码变更后重建过包时会自动重跑测试生成新覆盖率。[unit_test_ref.md](https://link.gitcode.com/i/9e2331ad538627839912345f8d918f36)对这两个工具的使用次序做了明确规定先以establish_baseline: true建立基线失败的基线属于既有的证据不是去编辑无关代码的许可用move_package_coverage聚焦目标函数或全包未覆盖行加完测试后再以非 baseline 模式运行用newly_covered度量新增覆盖。该工具的端到端行为由 src/tests/move_package_test/ 下的一组测试固化例如establish_baseline.rs、get_uncovered.rs、newly_covered.rs、coverage_filter_uncovered.rs等根据 CLAUDE.md 的说明这些测试以.exp基线文件记录输出可用UB1 cargo test -p aptos-move-flow重新生成。完整的测试生成工作流unit_test_tasks.md 定义了与上述规则、工具配套的标准 6 步流程被置于 Agent 提示词最前建立干净基线以 baseline 覆盖率模式运行既有测试不要为了掩盖既有失败而改生产代码或既有测试应报告它选择行为用例阅读被测函数或模块覆盖有意义的成功路径、不同的 abort、分支与边界值把未覆盖行当作证据而不是质量的全部定义编写隔离的生成测试新测试只放tests/move_flow/module_tests.move不改用户手写的测试验证并诊断修复生成测试中错误的 setup 或预期若正确的测试暴露了生产 bug把复现用例保留在bugs/下并报告而不是改动断言去凑通过审查覆盖率与冗余行为不同的用例即使覆盖同一行也保留只删除行为与覆盖都重复的生成测试报告结果列出新增用例、是否全部通过、获得了哪些有效覆盖以及任何疑似产品缺陷。小结unit_test_rules.md 虽然只有百余行但它构成了 MoveFlow 插件中AI 写 Move 单元测试这一能力的规则核心属性表与 signer 绑定定义了语法边界#[expected_failure]的精确匹配纪律定义了失败用例的写法测试设计准则与命名约定定义了质量底线再结合 unit_test_ref.md 的落位约束、unit_test_tasks.md 的 6 步流程以及 package_test.rs 中move_package_test/move_package_coverage的基线与覆盖率对比实现形成了一套从语法、设计到工具链的完整单元测试规范。若要在自己的 Move 包中复用这套规范可参考其模板结构cont/templates/ Tera include并以cargo install --path aptos-move/flow --locked --profile ci安装 move-flow 后通过其 MCP 工具链驱动测试与覆盖率流程见 aptos-move/flow/CLAUDE.md。【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Aptos MoveFlow 中的 Move 单元测试编写规范：test 属性、预期失败与覆盖率基线工作流
Aptos MoveFlow 中的 Move 单元测试编写规范test 属性、预期失败与覆盖率基线工作流【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core本文基于 aptos-core 仓库中 MoveFlow 插件的模板文件 unit_test_rules.md 展开。该模板是 MoveFlow位于 aptos-move/flow 的 Claude Code 插件提供 MCP 服务器、插件生成器与编辑 Hook注入给 AI Agent 的 Move 单元测试语法规则与测试设计准则。读完本文你将掌握 Move 单元测试的全部核心属性#[test]、#[expected_failure]、#[test_only]及其变体用法、signer 绑定机制、常用测试工具函数以及配套的覆盖率基线baseline工作流在 MCP 工具中的底层实现。模板在 MoveFlow 中的定位unit_test_rules.md 是一个 Tera 模板片段文件以{# Move unit testing rules #}注释开头并使用{% if once(nameunit_test_rules) %} ... {% endif %}包裹保证被多个 Agent/Skill 重复 include 时只渲染一次。根据 CLAUDE.md 的说明cont/目录下的模板通过 Tera 语法组织为四类cont/agents/Agent 指令文件、cont/skills/技能定义、cont/hooks/事件 Hook 配置与cont/templates/被 include 的共享片段。该规则片段被以下文件引用最终进入move-test技能与 Agent 的提示词unit_test_ref.md单元测试参考材料通过{% include templates/unit_test_rules.md %}引入本片段并追加工具使用说明与生成测试的位置约束unit_test_tasks.md测试生成工作流的 6 个步骤被放在 Agent 提示词最前面move-test/SKILL.md 与 move-test.md分别组装 tasks ref 两部分内容。因此理解本规则片段时应把它看作AI 编写 Move 单元测试时必须遵守的语法规则 设计规范而非面向人的泛泛教程。Move 单元测试语法测试属性Test Attributes模板给出了完整的属性对照表这是编写任何 Move 单元测试的入口属性用途#[test]将函数标记为测试#[test(name addr)]测试函数中 signer 参数绑定到指定地址#[test_only]仅编译进测试产物的代码模块、函数、struct、常量均可#[expected_failure]预期会 abort 的测试任意代码#[expected_failure(abort_code N)]预期以特定 abort code 中止#[expected_failure(abort_code N, location mod)]预期在特定模块位置中止Signer 参数绑定模板强调signer 通过 test 属性绑定而不是作为函数实参传入。函数签名中声明signer参数属性中给出参数名 地址的映射// 单个 signer #[test(account 0x1)] fun test_single(account: signer) { } // 多个 signer #[test(admin admin_addr, user 0x42)] fun test_multi(admin: signer, user: signer) { } // 框架 signer用于时间戳、创建账户等 #[test(aptos_framework aptos_framework)] fun test_framework(aptos_framework: signer) { }其中admin_addr、aptos_framework是 Move 包命名地址named address的引用写法在Move.toml中定义。预期失败Expected Failures模板规定用#[expected_failure]来验证代码在特定条件下确实正确中止优先写精确的 abort code 和 location只有当失败的种类本身就是被测行为时才使用无约束的#[expected_failure]。任意 abort#[test] #[expected_failure] fun test_will_abort() { abort 1 }带 abort code必须精确匹配#[test] #[expected_failure(abort_code E_NOT_AUTHORIZED, location Self)] fun test_unauthorized() { /* should abort with E_NOT_AUTHORIZED */ }带 location错误来源在另一个模块时#[test] #[expected_failure(abort_code 26113, location extensions::table)] fun test_table_error() { /* should abort in table module */ }执行错误非 abort而是运行时失败例如算术错误溢出、除零和 vector 越界// 算术错误溢出、除零 #[test] #[expected_failure(arithmetic_error, location Self)] fun test_overflow() { let _ 255u8 1; } // Vector 越界 #[test] #[expected_failure(vector_error, minor_status 1, location Self)] fun test_out_of_bounds() { vector::borrow(vector::emptyu8(), 0); }仅限测试的代码Test-only code#[test_only]既可标注整个模块整个模块只在测试时编译也可标注普通模块中的函数// 测试专用模块整个模块只在测试时编译 #[test_only] module my_addr::test_helpers { public fun setup(): u64 { 100 } } // 普通模块中的测试专用函数 module my_addr::my_module { #[test_only] public fun init_for_testing(account: signer, value: u64) { move_to(account, MyResource { value }); } }这与 MCP 工具侧的实现相呼应package_test.rs 中构造的BuildConfig设置了test_mode: true即测试编译走独立的 test 模式构建#[test_only]代码只存在于该模式下。常用测试工具模板列出的一组常用辅助操作// 从 signer 取地址 use std::signer; let addr signer::address_of(account); // 创建账户会在链上注册 use aptos_framework::account; account::create_account_for_test(addr); // 只创建 signer 不注册轻量 let signer account::create_signer_for_test(0x123); // 检查资源是否存在 assert!(existsMyResource(addr), E_NOT_FOUND); // 初始化时间戳调用时间函数前必须执行 use aptos_framework::timestamp; timestamp::set_time_has_started_for_testing(aptos_framework); // 推进时间 timestamp::update_global_time_for_test(1000000); // 微秒 timestamp::update_global_time_for_test_secs(100); // 秒测试设计规范Test design模板给出了四条设计准则与命名约定这部分直接约束 Agent 生成测试的质量每个测试只测一种行为并用到达该行为所需的最少 setup只要可见性允许就直接调用被测函数对无法访问的私有函数通过可观察的公共行为来测或使用已有的模块内测试模式——不要为了测试而修改生产代码的可见性注释要解释所检查的行为尤其是 abort 与边界情况断言语义结果而不是断言偶发的实现细节。命名约定函数名test_function_scenario如test_transfer_insufficient_balance测试模块名module_tests。常见错误RESOURCE_ALREADY_EXISTS不要对同一资源初始化两次MISSING_DATA调用前先确保所需资源存在Signer 不匹配凡是用signer::address_of()做鉴权检查的操作必须在 test 属性中把正确的 signer 绑定到预期地址。生成测试的落位与失败诊断参考材料 unit_test_ref.md 在本规则之外补充了工作流约束新生成的测试只允许创建或扩展tests/move_flow/module_tests.move且模块需带#[test_only]标注#[test_only] module package_address::module_tests { use package_address::module; #[test(account 0x1)] /// ai-generated /// Verifies that function behavior. fun test_function_scenario(account: signer) { ... } }对失败测试的诊断分三类编译错误——修测试本身setup 或断言写错——修正生成的测试疑似生产缺陷——把复现用例移到包根目录的bugs/下并记录预期 vs 实际除非用户明确要求否则不改生产代码。整个工作流中只允许编辑tests/move_flow/与bugs/下的生成文件。配套 MCP 工具的底层实现规则片段中的用法最终由两个 MCP 工具承载实现在 package_test.rs1.move_package_test——参数为package_path与establish_baseline源码。其响应结构TestResponse包含success、baseline_established仅 baseline 模式、newly_covered源码文件路径 → 新增覆盖行号集合仅正常模式与output失败时或无基线时的提示。关键行为Baseline 模式只在测试全部通过时才把当前覆盖率存为基线save_baseline_coverage_map源码确保基线反映一次有效的测试运行包内没有任何测试时则创建一个空基线。正常模式与基线对比返回基线中未覆盖、现在已覆盖的行compute_newly_covered源码测试失败时跳过覆盖率分析因为覆盖率图可能反映的是部分执行结果。基线文件保存在会话临时目录文件名用规范化的包路径哈希命名baseline_coverage_{hash}.mvcov使./pkg与绝对路径得到同一哈希避免碰撞源码。测试执行通过run_tests调用run_move_unit_tests固定TEST_GAS_LIMIT 100_000防止死循环挂起并启用覆盖率统计compute_coverage: true源码。2.move_package_coverage——参数package_path与可选的function: module::function源码。指定函数时用make_function_line_filter按函数在源码中的行范围过滤覆盖率图缺失、或源码变更后重建过包时会自动重跑测试生成新覆盖率。[unit_test_ref.md](https://link.gitcode.com/i/9e2331ad538627839912345f8d918f36)对这两个工具的使用次序做了明确规定先以establish_baseline: true建立基线失败的基线属于既有的证据不是去编辑无关代码的许可用move_package_coverage聚焦目标函数或全包未覆盖行加完测试后再以非 baseline 模式运行用newly_covered度量新增覆盖。该工具的端到端行为由 src/tests/move_package_test/ 下的一组测试固化例如establish_baseline.rs、get_uncovered.rs、newly_covered.rs、coverage_filter_uncovered.rs等根据 CLAUDE.md 的说明这些测试以.exp基线文件记录输出可用UB1 cargo test -p aptos-move-flow重新生成。完整的测试生成工作流unit_test_tasks.md 定义了与上述规则、工具配套的标准 6 步流程被置于 Agent 提示词最前建立干净基线以 baseline 覆盖率模式运行既有测试不要为了掩盖既有失败而改生产代码或既有测试应报告它选择行为用例阅读被测函数或模块覆盖有意义的成功路径、不同的 abort、分支与边界值把未覆盖行当作证据而不是质量的全部定义编写隔离的生成测试新测试只放tests/move_flow/module_tests.move不改用户手写的测试验证并诊断修复生成测试中错误的 setup 或预期若正确的测试暴露了生产 bug把复现用例保留在bugs/下并报告而不是改动断言去凑通过审查覆盖率与冗余行为不同的用例即使覆盖同一行也保留只删除行为与覆盖都重复的生成测试报告结果列出新增用例、是否全部通过、获得了哪些有效覆盖以及任何疑似产品缺陷。小结unit_test_rules.md 虽然只有百余行但它构成了 MoveFlow 插件中AI 写 Move 单元测试这一能力的规则核心属性表与 signer 绑定定义了语法边界#[expected_failure]的精确匹配纪律定义了失败用例的写法测试设计准则与命名约定定义了质量底线再结合 unit_test_ref.md 的落位约束、unit_test_tasks.md 的 6 步流程以及 package_test.rs 中move_package_test/move_package_coverage的基线与覆盖率对比实现形成了一套从语法、设计到工具链的完整单元测试规范。若要在自己的 Move 包中复用这套规范可参考其模板结构cont/templates/ Tera include并以cargo install --path aptos-move/flow --locked --profile ci安装 move-flow 后通过其 MCP 工具链驱动测试与覆盖率流程见 aptos-move/flow/CLAUDE.md。【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考