Hardhat项目中关于revertWithCustomError与Viem集成的技术解析

背景与问题场景

在智能合约测试过程中，错误断言是验证合约行为的重要环节。Hardhat作为流行的区块链开发环境，提供了hardhat-chai-matchers插件来扩展Chai断言库的功能。其中revertedWithCustomError是一个常用的匹配器，用于验证合约是否抛出了特定的自定义错误。

然而，当开发者尝试将这一功能与hardhat-viem（Hardhat的Viem集成）配合使用时，会遇到一个关键问题：从getContractAt获取的合约实例缺少interface属性，导致revertedWithCustomError无法正常工作。

技术原理分析

1. Ethers与Viem的架构差异：

   • Ethers.js的合约实例包含完整的ABI信息，通过interface属性暴露错误定义
   • Viem采用更轻量级的架构，合约实例不自动包含完整的接口定义

2. hardhat-chai-matchers的设计：

   • 该插件最初为Ethers.js设计，依赖interface属性来解析自定义错误
   • 错误匹配器需要访问合约ABI才能识别自定义错误的selector和参数

3. Viem的工作方式：

   • 提供更底层的RPC交互
   • 合约调用返回的错误信息格式与Ethers不同
   • 需要额外的错误解码层

当前解决方案

在Hardhat 3.0发布Viem专用匹配器之前，开发者可以采用以下替代方案：

1. 基础错误断言：

await expect(contract.write.grantMinter([address]))
  .to.be.rejectedWith("预期的错误消息");

2. 手动错误解码：

   • 通过Viem的decodeErrorResult手动解析revert数据
   • 需要预先知道错误ABI定义

3. 临时封装方案：

function withCustomError(contract, errorName) {
  return {
    async assert(receipt) {
      const error = await decodeCustomError(contract, receipt);
      if(error.name !== errorName) {
        throw new Error(`Expected ${errorName} but got ${error.name}`);
      }
    }
  }
}

最佳实践建议

1. 项目技术栈统一：

   • 新项目建议统一使用Ethers或Viem全套工具链
   • 避免混合使用不同生态的测试工具

2. 错误测试策略：

   • 对于关键业务错误，建议增加错误码的显式断言
   • 可以考虑将错误定义提取为共享常量

3. 升级规划：

   • 关注Hardhat 3.0的发布动态
   • 为Viem专用匹配器的引入预留升级路径

未来展望

随着Viem在区块链生态中的普及，Hardhat团队正在积极开发与之深度集成的测试工具。预计在Hardhat 3.0中将会提供：

1. 原生支持Viem合约实例的错误匹配器
2. 更精细的错误解码和断言能力
3. 与TypeScript更好的类型集成

开发者可以保持对Hardhat更新日志的关注，及时获取最新的Viem集成进展。对于当前项目，建议根据实际需求选择合适的临时解决方案，并在技术栈升级时进行相应的测试代码迁移。