你可能已经见过不少项目把 Solidity 测试写在 JavaScript/TypeScript 里通过 Hardhat 配 Mocha、Waffle 或 ethers 来跑这套组合在生态里成熟、资料多但也确实有让人头疼的地方测试代码是另一种语言部署脚本要写 async/await断言库要额外装跑了半天还可能因为某个 RPC 节点超时挂掉。Foundry 的到来几乎是在说既然合约是 Solidity 写的为什么测试不能用 Solidity 写它把测试、部署、脚本、查链工具全部塞进一套以 Solidity 为中心的工具链里核心就是forge test一条命令跑完整个测试流程。这篇文章我会从零开始带你装好 Foundry、初始化项目、写第一组 Solidity 测试然后逐步深入到 cheatcode、fork 测试、模糊测试这些实际开发中真正高频使用的功能。无论你是刚接触 Solidity 测试的新手还是想从 Hardhat 迁移过来的 Web3 开发者这套流程都能直接照着做。1. 为什么选 Foundry 写 Solidity 测试和 Hardhat 那套有什么本质不同1.1 “测试即代码”这件事真的不是噱头先说一个最直观的区别。在 Hardhat 生态里测试代码长这样const { expect } require(chai); const { ethers } require(hardhat); describe(Bank, function () { it(should deposit, async function () { const Bank await ethers.getContractFactory(Bank); const bank await Bank.deploy(); await bank.deposit({ value: 100 }); expect(await bank.balanceOf(owner.address)).to.equal(100); }); });而在 Foundry 里同样一个测试长这样// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import {Test, console2} from forge-std/Test.sol; import {Bank} from ../src/Bank.sol; contract BankTest is Test { Bank bank; function setUp() public { bank new Bank(); } function test_Deposit() public { bank.deposit{value: 100}(); assertEq(bank.balanceOf(address(this)), 100); } }测试合约本身就是一个 Solidity 合约setUp()函数在每条测试用例前执行test开头的函数会被自动识别为测试用例。你不用再去记 Chai 的断言语法也不用纠结await什么时候该加assertEq、assertTrue、assertGt这些断言都是 forge-std 提供的内置函数直接写、直接跑。这套设计带来的第一个实际好处是速度。Foundry 编译完合约之后测试直接发生在原生的 EVM 环境里没有复杂的 RPC 通信和 JSON-RPC 序列化过程。我自己的体验是跑一个几百个用例的项目Hardhat 可能要一两分钟Foundry 通常是几秒到十几秒。对于需要频繁验证逻辑的迭代阶段这个差异会直接改变你的开发习惯——你不再怕跑测试费时间于是会更愿意跑。第二个好处是状态控制能力。Foundry 提供了一套 cheatcode也就是测试环境里对 EVM 的特殊操作接口比如修改msg.sender、修改任意地址余额、调整区块时间。这些操作在 Hardhat 里往往要借助evm_mine之类的外部方法或者依赖插件而在 Foundry 里就是一行vm.prank(...)直观又强大。第三个容易被忽略的好处是共识。测试代码和业务代码用同一种语言团队里的 Solidity 开发者可以直接看懂测试逻辑而不用在 JS 和 Solidity 两套思维里反复横跳。新人上手时TestCase 读起来就像一份可执行的合约行为文档。1.2 这套方案适合什么项目又有哪些前提Foundry 并不是要取代所有 Web3 开发工具。它格外适合以下几类场景核心是合约逻辑、需要大量单元测试和边界验证的项目比如 DeFi 协议、借贷合约、AMM、治理模块。需要做高覆盖率测试、模糊测试和复杂权限控制的合约Foundry 的 fuzz 和 invariant 测试支持得非常好。依赖链上现有协议的集成项目可以用 fork 模式直接测试与 Uniswap、Compound 这类协议的交互不用先在本地部署一堆 mock。但如果你只是写一个简单的 NFT 合约并且前端团队需要 JS 测试脚本做整体联调Hardhat 可能更顺手。Foundry 也不适合完全不懂 Solidity 的人直接入门——你至少得知道构造函数、状态变量、外部调用这些基础概念否则测试代码里全是看不懂的语法。另外Foundry 对运行环境有一定要求建议在 macOS 或 Linux 环境下使用Windows 用户最好通过 WSL2 跑需要系统装有git和curl。这些工具本身不复杂但确实是开始前的硬前提。2. 环境搭建与项目初始化从装工具到跑通第一个 build2.1 四个核心命令工具forge、cast、anvil、chiselFoundry 不是单一程序而是一套工具链安装时一次会装上四个主要命令forge核心武器负责项目初始化、编译、测试、部署脚本执行、覆盖率分析等。cast链上交互工具可以查余额、查交易、调用合约、解码 calldata开发调试的时候非常有用。anvil本地开发节点相当于 Hardhat 里的本地链可以在测试环境快速起一个链。chiselSolidity 交互式 REPL可以在命令行里写 Solidity 代码试运行适合快速验证小段逻辑。安装方法在官方文档里写得很简单就两条命令curl -L https://foundry.paradigm.xyz | bash执行之后会在你的 home 目录下安装foundryup命令。注意curl | bash这种方式在实际生产环境里容易被安全审计问罪但 Foundry 官方一贯采用这种方式你在自己本地开发机执行没问题。装完foundryup后再执行foundryup这一步会拉取预编译好的工具链并安装到~/.foundry/bin目录。安装结束以后建议先source ~/.bashrc或source ~/.zshrc刷新环境变量再检查版本forge --version如果输出类似forge 1.0.0 (abcdef1 2025-01-01T00:00:00.000000000Z)这样的版本信息就说明环境已经就绪。以后想更新版本再跑一次foundryup就行它会自动下载更新版本并覆盖这是这套工具链里最省心的一点。2.2 forge init 之后项目目录里到底放了些什么创建一个新项目很简单forge init my-web3-test cd my-web3-test forge buildforge init会拉一个默认模板包含一个最小合约和一个对应的测试文件。执行完以后项目里会生成这样一些目录和文件my-web3-test/ ├── foundry.toml ├── remappings.txt ├── script/ │ └── Counter.s.sol ├── src/ │ └── Counter.sol ├── test/ │ └── Counter.t.sol └── lib/ └── forge-std/这些目录的命名和用途需要理清楚因为它们会影响你后续放文件的位置src/存放合约源码。默认模板里的Counter.sol就是个简单的计数器合约功能和说明文档一致。test/存放测试合约。默认文件名Counter.t.sol用.t.sol后缀标记这是一个测试文件方便工具识别。script/存放部署和操作脚本Sol文件的命名习惯是Counter.s.sol。lib/存放外部依赖库默认已经装好了forge-std这是 Foundry 的标准测试库。foundry.toml核心配置文件编译参数、EVM 版本、优化器开关都在这里。remappings.txt路径映射文件解决 import 时库的路径对应问题。这时候你执行forge build如果能看到类似Compiling 5 files with 0.8.23这样的日志输出并且最终出现Success说明基础项目已经可用了。默认模板里自带的Counter合约和测试可以直接用forge test跑通这可以帮你在改动任何代码之前先确认工具链没有毛病。2.3 remappings 和 foundry.toml 里的关键配置用 Foundry 写测试大概率会碰到import {Test} from forge-std/Test.sol这样的导入语句。这个forge-std为什么不用写相对路径靠的就是 remappings。安装依赖用forge install foundry-rs/forge-std安装完成后项目里会出现lib/forge-std目录同时remappings.txt里会自动添加一行forge-std/lib/forge-std/src/它的意思是所有以forge-std/开头的 import 路径都去lib/forge-std/src/目录下找真实文件。你也可以在foundry.toml里用remappings [openzeppelin/lib/openzeppelin-contracts/]这样的写法声明映射两种方式效果一样。装完依赖、写了新引入后如果 IDE 还是报找不到文件多半是 remappings 没更新跑一下forge remappings看输出如果跟你预期不一致手动改一下remappings.txt即可。foundry.toml里最常用的配置项这些[profile.default] src src out out libs [lib] solc_version 0.8.23 optimizer true optimizer_runs 200 evm_version cancun ffi false其中solc_version建议固定成项目实际使用的版本防止拿不同编译器版本编译出现意外差异。evm_version跟编译器版本和部署目标链都有关系如果用到比较新的 opcode比如 Cancun 升级引入的TSTORE、MCOPY就必须设置成cancun。后面在问题排查部分我还会具体讲这个坑。3. 从零开始编写第一组测试一个简单 Bank 合约的全流程3.1 写一个带存取款功能的合约搭建测试骨架为了不浪费时间在模板的 Counter 上我们直接写一个稍微有点业务逻辑的合约。假设我们有一个Bank合约核心功能是存款和取款// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract Bank { mapping(address uint256) private _balances; address public owner; event Deposited(address indexed account, uint256 amount); event Withdrawn(address indexed account, uint256 amount); constructor() { owner msg.sender; } function deposit() external payable { require(msg.value 0, deposit amount must be 0); _balances[msg.sender] msg.value; emit Deposited(msg.sender, msg.value); } function withdraw(uint256 amount) external { require(amount _balances[msg.sender], insufficient balance); _balances[msg.sender] - amount; payable(msg.sender).transfer(amount); emit Withdrawn(msg.sender, amount); } function balanceOf(address account) external view returns (uint256) { return _balances[account]; } }这个合约虽然简单但已经覆盖了测试中最重要的三类行为状态变更存款后余额增加。条件校验取款超过余额会 revert。事件输出存取款都会触发事件。接下来在test/目录下新建文件Bank.t.sol写测试骨架// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import {Test, console2} from forge-std/Test.sol; import {Bank} from ../src/Bank.sol; contract BankTest is Test { Bank bank; address alice address(0x1111); address bob address(0x2222); function setUp() public { bank new Bank(); vm.deal(alice, 100 ether); vm.deal(bob, 100 ether); } }这里有个关键点setUp()会在每一条测试用例执行前运行所以每个测试函数都会拿到一个全新的bank合约实例。测试合约本身会作为默认的调用者也就是说bank.deposit{value: ...}()的msg.sender是这个BankTest合约地址而不是外部 EOA 地址。后面需要用alice、bob这类角色做权限隔离时就要用到vm.prank这类 cheatcode。3.2 断言、事件和 revert 一起上把行为锁死先写最基础的存款测试function test_Deposit_IncreasesBalance() public { bank.deposit{value: 1 ether}(); assertEq(bank.balanceOf(address(this)), 1 ether); } function test_Deposit_RejectZeroValue() public { vm.expectRevert(bytes(deposit amount must be 0)); bank.deposit{value: 0}(); }这两条用例分别覆盖了正面行为和负面行为。assertEq是 forge-std 里最常用的断言函数支持uint256、address、bytes32、string等多种类型。vm.expectRevert则用来声明下一条调用应该 revert如果预期错误信息和实际 revert 原因不一致测试会失败。再看事件断言。Foundry 里常用vm.expectEmit做事件断言被很多人忽略但它是确保合约事件输出稳定的关键手段。写法是先用emit声明预期事件再执行业务调用function test_Deposit_EmitsEvent() public { vm.expectEmit(true, true, true, true); emit Deposited(address(this), 5 ether); bank.deposit{value: 5 ether}(); }expectEmit的四个 bool 参数分别表示from、to、topics、data是否需要严格比对。对 indexed 参数的匹配和topic0的处理建议先按文档的默认用法来等需要精确定位某个 topic 时再逐个调整。实际开发中我更喜欢把事件校验和状态断言同时写在同一个测试函数里这样一次调用能验证两件事测试数量不会过于庞大。再补一个取款相关的用例function test_Withdraw_DecreasesBalance() public { bank.deposit{value: 3 ether}(); bank.withdraw(2 ether); assertEq(bank.balanceOf(address(this)), 1 ether); } function test_Withdraw_FailsWhenExceedingBalance() public { bank.deposit{value: 1 ether}(); vm.expectRevert(bytes(insufficient balance)); bank.withdraw(2 ether); }注意这里测试函数名里的下划线是我故意保留的。Foundry 只要求函数以test开头下划线分隔能起到“行为 期望结果”的作用比如test_Withdraw_DecreasesBalance读起来就是“取款减少余额”一目了然。早期我不会刻意维护这套命名规范后来项目大了才意识到测试函数名本身就是最好的行为文档。3.3 运行测试与读懂输出不只会跑还要会看日志运行测试只需要forge test如果一切正常你会看到类似这样的输出Running 5 tests for test/Bank.t.sol:BankTest [PASS] test_Deposit_EmitsEvent() (gas: 98541) [PASS] test_Deposit_IncreasesBalance() (gas: 97824) [PASS] test_Deposit_RejectZeroValue() (gas: 83456) [PASS] test_Withdraw_DecreasesBalance() (gas: 78542) [PASS] test_Withdraw_FailsWhenExceedingBalance() (gas: 78901) Suite result: ok. 5 passed; 0 failed; 0 skipped; finished in 12.80ms[PASS]后面的括号里是本次调用的 gas 消耗这个值对合约优化有直接参考价值。如果某些用例失败你会看到[FAIL. Reason: ...]和具体到行号的错误信息同时测试套件会给出失败统计。forge test支持很多输出级别用-vv、-vvv、-vvvv控制日志详细程度-vv显示测试函数内的 console 日志。-vvv显示每个调用栈的 trace。-vvvv把存储变量、调用数据、revert 原因全量打印。实际调 bug 或排查 revert 原因时-vvvv基本是标配。另外如果只想跑某个测试文件或某个特定测试函数不用--match-path和--match-test两个参数forge test --match-path test/Bank.t.sol forge test --match-test test_Withdraw_DecreasesBalance这两个参数支持正则表达式可以快速筛出你关心的用例省掉大量无效输出。4. 测试进阶用 cheatcode 模拟真实链上环境覆盖复杂场景4.1 prank、deal、warp 三个高频 cheatcode 的实战用法Foundry 的 cheatcode 是测试框架中价值密度最高的部分所以值得单独拆开讲。最常用的三个是vm.prank、vm.deal、vm.warp。vm.prank(address)的作用是把下一次调用的msg.sender设置为指定地址执行完成后立即恢复。这是测试权限控制的核心工具比如我们要验证只有 owner 才能调某个函数可以这样function test_OnlyOwnerCanChangeConfig() public { vm.prank(bob); vm.expectRevert(not owner); bank.setOwner(bob); }如果需要在连续多次调用中都保持某个调用者身份可以用vm.startPrank和vm.stopPrank包裹一段代码块。这里有个坑如果你startPrank之后忘了stopPrank后续这条测试里所有调用都会带上这个伪造身份很容易导致莫名其妙的失败。我的习惯是只伪造一次调用就用prank需要连续伪造再用startPrank/stopPrank配对并且尽量把业务逻辑放在一个带缩进的代码块里保持肉眼可定位。vm.deal(address, uint256)直接给指定地址设置余额不需要真的转一笔 ETH。上面的测试骨架里我用它给alice和bob各发了 100 ether这样就能以他们的身份跑存取款逻辑。它比在 JS 环境里手动转账、再等确认要快得多。vm.warp(uint256)可以调整当前环境的时间戳vm.roll(uint256)可以调整区块高度。时间相关合约比如质押、锁仓一定要配上这两个函数来测。比如一个锁仓合约锁定 30 天测试时不需要真的等 30 天直接在setUp里vm.warp(block.timestamp 30 days)然后验证取回逻辑即可。要注意的是vm.warp之后block.timestamp会变成你设置的值但block.number不会自动增加需要时间推进配合区块高度变化时手动同时设置vm.roll。4.2 fork 主网测试在测试里直接跟真实协议交互有些合约需要和链上已经存在的协议交互比如你的合约要调用 Uniswap 的 swap 接口。这种情况下本地重新部署一个 Uniswap 全套几乎不可能。Foundry 支持 fork 测试也就是说本地测试环境可以挂载到某个 RPC 节点上直接把主网或测试网的状态拉进来。常用方式是在foundry.toml里配置[rpc_endpoints] mainnet https://eth.llamarpc.com然后在跑测试时指定 fork URLforge test --fork-url mainnet也可以写成环境变量方式forge test --fork-url $MAINNET_RPC_URLfork 模式下的关键点在于你在测试中做的任何写入操作都不会真的发到链上而是发生在一个基于fork状态的临时 EVM 里只有读取状态是来自真实链的。这就像你拿到一份线上数据的快照在本地做了一个“假设改动”一次验证多个分支。实际使用中有几个小技巧。第一fork 后地址的私钥需要用vm.addr(uint256)从私钥推导不要写死地址但拿不到私钥容易在后续调用里因为msg.sender权限不足而失败。第二刚好有依赖多链合约的项目建议把测试用的 RPC URL 配置到独立环境中统一管理不要硬编码在yml或脚本里。第三fork 模式下单次测试速度会比本地模式慢不少毕竟需要从 RPC 拉取状态尽量在测试文件里做好分层把需要 fork 的用例单独拎到一个目录、用--match-path控制。4.3 模糊测试与不变量测试让机器替你“找茬”模糊测试Fuzz Testing是 Foundry 最让人兴奋的能力之一。普通的测试函数只能固定一组参数而 fuzz 测试函数可以声明参数Foundry 会自动生成大量随机值来跑测试。比如function testFuzz_Deposit_AlwaysIncreasesBalance(uint256 amount) public { amount bound(amount, 1, 100 ether); bank.deposit{value: amount}(); assertEq(bank.balanceOf(address(this)), amount); }注意这里用bound函数把amount限制在合理范围内防止随机值过大导致算术溢出或 gas 耗尽。bound是 forge-std 提供的便捷函数底层是通过%取模比vm.assume更可控、更不容易因为样本被丢弃而影响整体覆盖率。模糊测试的价值在于它会自动寻找那些你可能没考虑到的边界输入。比如你写了一个uint256参数但忘记处理0值可能跑上百个固定用例都不会踩到但 fuzz 跑几秒钟就能把它暴露出来。实际项目中对算术逻辑、奖励计算、汇率换算这类合约我基本都会配一两个 fuzz 测试。不变量测试Invariant Testing是更进一步的验证方式。它是指合约在任意随机操作序列下某个状态属性始终不变。比如“用户总存款等于每个用户余额之和”无论你怎么存取款这个等式都必须成立。Foundry 里的不变量测试写法稍微特殊一般约定函数名以invariant_开头并且要实现targetContract来告诉测试框架要随机调用哪个合约contract BankInvariantTest is Test { Bank bank; function setUp() public { bank new Bank(); targetContract(address(bank)); } function invariant_TotalSupplyMatchesSum() public view { uint256 total bank.totalBalance(); assertEq(total, bank.balanceOf(address(this)) bank.balanceOf(alice) bank.balanceOf(bob)); } }不变量测试特别适合做底层协议的安全验证比如 AMM 里的恒定乘积公式、借贷协议里的抵押率下限。不过它需要合约能接受随机调用如果合约有大量onlyOwner之类的权限限制记得在setUp里通过vm.startPrank设置白名单或用excludeContract排除掉无关合约否则测试框架随机调用时会被权限卡住生成一堆假阳性。5. 工具链协同覆盖率、快照与调试把测试数据用起来5.1 用 forge coverage 找到你的测试盲区光知道测试全过还不够还得知道你到底测到了多少代码。Foundry 内置覆盖统计直接跑forge coverage它会输出合约各文件的覆盖情况包括行覆盖率、分支覆盖率。比如某个分支只有在amount 0时才会触发而你从没测过覆盖率报告会把它标红并提示你。这个报告最直观的用法是检查新增合约的测试压力。每次写完一个合约我一般先跑一下forge coverage看看初始覆盖情况然后回去补测试。行覆盖率到 90% 以上是比较健康的水平如果某件事特别难测比如依赖大量外部状态至少要保证核心逻辑覆盖到。分支覆盖率比行覆盖率更重要因为它能抓到“某个 if 分支从来没被踩过”的问题。如果想生成更详细的 HTML 报告可以设置forge coverage --report lcov生成 LCOV 格式再配合 VS Code 插件或genhtml工具可视化。这对团队做测试门槛检查非常有效建议 CI 里直接加一条“覆盖率低于阈值就不允许合并”的检查。5.2 用 forge snapshot 看住 gas 成本防止优化随时间退化合约开发者经常会忽略 gas 成本的长期变化但有时候一次无意的代码改动会让核心函数的 gas 消耗飙升几万。Foundry 的 snapshot 功能就是用来盯住这条线的。跑一次forge snapshot它会在项目根目录生成一个.gas-snapshot文件内容是每个测试函数的 gas 消耗快照。之后当你改了代码再跑一次forge snapshot --diff它就能对比当前 gas 与上次快照的差异直接告诉你哪些函数成本上涨了。这个能力在重构合约时尤其好用。我经常在重构前生成一份 snapshot重构后再 diff 一次用数据判断这次重构是变好了还是变差了。CI 里也可以加“gas diff 超过阈值则失败”的检查这样项目组的公共合约不至于默默膨胀。需要注意的是.gas-snapshot是文本文件应该纳入版本控制否则 diff 就失去基准。如果你希望某类用例不参与 snapshot可以在测试函数声明里不写test前缀或者用forge snapshot --skip参数。这个细节很容易被忽略但影响很大。5.3 快速定位失败用例从-vvvv到cast的调试武器库测试失败的排查是实际开发里最常花时间的部分。我先说一个最基础却最有效的办法forge test --match-test 失败函数名 -vvvv。这会输出完整的调用 trace包括每个地址的调用关系、传递的 calldata、产生的日志、以及 revert 的具体位置。很多失败其实一眼就能从 trace 里看出来比如某个地址不是合约或者某个调用者权限不对。如果需要看合约内部某个变量在中间步骤的值别用 Solidity 的字符串拼接那一套。forge-std 提供了 console 合约import {console2} from forge-std/console2.sol; function test_Debug() public { console2.log(balance before:, bank.balanceOf(alice)); // ... }console2会经过编译器优化处理注入更精确的日志信息支持打印各种基本类型和数组。调试完记得把 console2 的 import 和日志代码删掉否则这些日志会留在合约代码里增加部署字节码体积。还有一种情况是测试通过了但你不确定链上真实状态是否符合预期。这时候可以用cast单独查链上数据。比如cast call 0x合约地址 balanceOf(address)(uint256) 0x钱包地址 --rpc-url mainnetcast还能解码交易、查 block、算 selector日常排查问题的时候它的地位完全不亚于forge。记住一个原则forge负责本地开发循环cast负责链上真相核对两者配合使用才能快速判断问题是出在合约逻辑还是测试环境模拟不对。6. 常见问题与排查技巧实录这些坑我基本每个都踩过6.1 编译失败、版本冲突和 EVM 版本设置最常见的项目刚克隆下来forge test直接报编译错误错误信息里经常出现Compiler version not found。根本原因是foundry.toml没指定具体的solc_version而 Foundry 默认会自行选择或从远端下载一个版本。解决办法是solc_version 0.8.23固定版本后项目内所有依赖都用同一个编译器能大幅减少偶发的不兼容问题。如果你的合约依赖 OpenZeppelin 之类的库也要确认库要求的版本和solc_version兼容。依赖库和源码版本不一致时编译错误可能五花八门比如找不到库符号、函数签名不匹配。另一个经常被忽视的问题是 EVM 版本。如果合约里用了比较新的类型或操作码比如自定义错误、beacon相关操作、mcopy等而你配置的evm_version太老编译会直接失败。一般建议跟随主流链更新比如以太坊主网已经支持 Cancun 相关操作码那么evm_version cancun是合理选择。但要注意如果你部署的目标链还没升级到对应版本即使本地编译通过部署后调用也会崩溃所以 EVM 版本要从实际部署链出发而不是只为了编译通过。6.2 测试写着写着跑不通地址与存储的边界条件刚开始写 Foundry 测试的人最容易踩的一个坑是测试合约地址本身也是合约地址它和外部用户地址不同。在Bank测试里address(this)是BankTest合约地址如果你在setUp里没有给它发 ETH那么任何deposit{value: ...}都可能因为余额不足而失败。很多奇怪的“回滚原因说不清”其实都是这个引起的。另外一个高发问题出现在vm.prank的时序上vm.prank(alice); bank.deposit{value: 1 ether}(); bank.withdraw(1 ether); // 这里仍然以为是 alice 在调用但实际是测试合约地址vm.prank只影响紧接着的这一次调用。如果你在它后面又写了好几行业务逻辑后面的调用者身份是address(this)并不是你预想的alice。这种问题跑起来就是权限不足查 trace 才能看出来。解决办法是需要连续改变调用者时用vm.startPrank(alice)开头所有逻辑执行完后再vm.stopPrank()或者在每一段关键调用前面重新设置一次vm.prank。还有一类存储相关的问题是Foundry 测试之间状态是隔离的每条测试用例在执行前都会重新执行setUp()。有些新手会在setUp里给测试合约打 ETH结果某条用例里改了状态下一条用例里没更新预期导致结果对不上。不要指望一个测试函数里改的状态能传导到另一个测试函数这种隐性耦合一定要主动避免。6.3 经验清单按这套方式来写测试才不容易返工我在喂了几年测试框架的苦头之后总结了一套自己的测试编写习惯这里分享给你。第一测试函数命名尽量带行为和预期结果。不要写test1、test2这种名字而是用test_Deposit_ShouldRevert_WhenAmountIsZero这种风格。等你有 200 个测试函数后会发现这个名字直接决定了定位问题的速度。第二一个测试函数只验证一个核心行为。有些人喜欢一个大函数里连续做十个断言失败的时候根本不知道是第几个断言的锅。建议把场景拆分比如“存款成功后余额增加”和“存款成功后触发事件”是两个不同关注点拆开写。第三先写测试再写合约。Foundry 的 TDD 体验非常好先定义好测试里期望的行为比如函数名、参数、revert 条件再去src里实现实现完了直接跑测试验证。这么做的好处是你会从“这个合约应该怎样被使用”的视角出发而不是“我要怎么把当前的烂代码补个测试”。第四善用 fuzz 和不变量测试但不要无脑加。游戏规则是逻辑复杂或算术运算多的地方优先考虑 fuzz协议核心不变量必须加 invariant普通的分支判断用固定参数就好。测试过多反而会拖慢整个 CI 流水线所以要有取舍。第五把测试当成合约行为的补充文档。当我接手一个新项目时第一件事不是读源码而是读它的测试文件。测试怎么写的基本就代表了这个合约有哪些外部行为、有哪些限制条件。写测试时多花点功夫后面所有人都会感谢你。最后分享一个我自己的习惯每写完一个合约我会先写一个“基础冒烟测试”只验证最核心场景能不能跑通再在它基础上逐步补充异常分支和边界条件。这样做的好处是即使后面测试越写越多最核心的保障始终在最前面任何一个改动都能第一时间发现基础功能是否被破坏。坚持这套节奏两周后你会发现写合约的底气和之前完全不一样。