ch02-11 Move 单元测试和 test_scenario

先建立手感

这一节用“Move 单元测试和 test_scenario”训练 Move 手感：先看对象和资源能不能被复制、丢弃、转移，再回到 DeepBook 里判断为什么这些限制有实际价值。

Move 对照

先用下面几处源码建立 Move 概念的落点。这里不追完整协议流程，只确认类型、ability、对象、事件和测试入口如何在真实项目中出现。

packages/deepbook/sources/hello_move.move
packages/deepbook/sources/pool.move
packages/deepbook/sources/balance_manager.move
book/ch02/code/s03-shared-object/README.md

读这些文件时，把语法点和真实对象放在一起看：ability、泛型、对象 ID、事件和测试入口分别承担什么约束。

拆开来看

Move 单元测试通常放在同包源码或测试模块中，使用 #[test]、#[test_only] 标注。hello_move.move 末尾提供 #[test_only] public fun test_helper_function(): u64，说明测试辅助函数可以只在测试环境可见。

Sui 对象交互测试常用 sui::test_scenario 模拟多交易、多地址、多对象流转。ch02 示例 book/ch02/code/s01-hello-move 会给出最小包的 build/test 命令，后续章节再扩展到场景测试。

实践中，每次修改 Move 示例后先运行：

sui move build
sui move test

阅读补充

Move 单元测试适合验证纯逻辑、资源约束和 abort 条件；test_scenario 适合模拟多交易、多地址和对象所有权变化。DeepBook 完整下单依赖多个共享对象和资产状态，测试时应先拆成更小的模块行为。

写测试时不要只覆盖成功路径。金融协议文档中的检查问题最好都能变成一个 abort 测试：错误权限、错误资产类型、数量不满足 lot size、版本关闭等。

Move 判断

先测小模块资源约束，再组合交易场景。
每个 abort 分支至少保留一个可读测试名称。
多地址场景要显式切换 sender，避免误判所有权。

练习问题

普通 Move 单元测试和 test_scenario 各适合什么问题？
DeepBook 下单为什么不适合一开始就写成超大集成测试？
哪些文档检查问题可以转成 abort 测试？

Keyboard shortcuts