Stellar Core测试框架演进：从SQL到BucketListDB的兼容性改造

在分布式账本系统Stellar Core的开发过程中，测试框架的演进正经历着重要的技术转型。随着核心存储架构从传统的SQL数据库向BucketListDB迁移，测试套件的兼容性改造成为保证系统可靠性的关键任务。

背景与挑战

当前测试框架中存在一个显著的技术债务：大量针对TransactionFrame和LedgerTxn的测试用例仍然直接操作SQL数据库。这种测试方式绕过了关键的ledgerClose逻辑流程，导致测试数据无法正确写入BucketList存储结构。随着SQL支持将被逐步淘汰，这种测试模式将无法验证真实生产环境下的系统行为。

技术影响分析

这种测试模式存在三个主要技术缺陷：

1. 存储层行为不一致：直接操作SQL跳过了BucketList的写入路径，无法验证数据持久化的完整流程
2. 测试覆盖缺口：关键的状态转换和持久化逻辑未被充分验证
3. 未来兼容风险：当完全移除SQL支持后，这些测试将无法运行

改造方案

技术团队制定了分阶段的改造计划：

第一阶段：修复端到端模拟测试

作为最优先任务，团队已经完成了端到端模拟测试的改造。这些测试现在能够：

• 完整执行账本关闭流程
• 验证BucketListDB的写入路径
• 确保数据持久化的正确性

第二阶段：全面测试审计

计划中的测试套件审计将：

• 识别所有依赖SQL的测试用例
• 评估测试覆盖率的缺口（如升级路径测试）
• 建立测试用例与存储后端的映射关系

第三阶段：测试策略重构

对于仍需内存账本但不依赖BucketList的测试：

• 显式启用SQL支持
• 通过测试配置隔离存储后端
• 保持测试框架的灵活性

技术决策考量

在改造过程中，团队面临几个关键决策点：

1. 测试粒度的平衡：在单元测试与集成测试间找到适当的抽象层级
2. 执行效率的权衡：BucketListDB测试通常比纯内存测试更耗时
3. 向后兼容的需求：过渡期间需要同时支持两种存储后端

未来方向

这项改造工作为Stellar Core的存储架构演进奠定了基础。随着改造完成，系统将能够：

• 完全移除对SQL的依赖
• 统一测试和生产环境的存储路径
• 提高测试对真实场景的模拟精度

这项系统性改造不仅解决了当前的技术债务，也为Stellar Core未来的架构演进提供了可靠的测试保障。通过这次改造，团队建立了更健壮的测试方法论，能够更好地应对分布式账本系统的演进需求。