compliance/memory-bank/refactoring_opportunities.md

架构重构机会

本文档记录了在开发过程中发现的、有价值的但因当前优先级或工作量而暂未实施的架构重构机会。旨在为未来的代码质量提升和迭代开发提供清晰的路线图。

1. 改进 APITestOrchestrator 的依赖注入和生命周期管理

当前问题与"不优雅"的根源

在为测试用例引入 SchemaProvider 作为核心依赖时，我们遇到了一个典型的 对象生命周期与依赖注入时序问题。

1. 理想的设计 是由框架（APITestOrchestrator）在初始化时创建并持有一个全局唯一的 SchemaProvider 实例，然后在创建测试用例时，将这个实例 注入 进去。
2. 现实的障碍 是 SchemaProvider 的创建依赖于 global_api_spec（即解析后的API规范文件），而 global_api_spec 本身是在 APITestOrchestrator 实例化很久之后，在 run_tests_from_yapi/swagger 等方法内部才被加载和创建的。
3. 导致的结果 是我们无法在 APITestOrchestrator 的 __init__ 方法中优雅地创建 SchemaProvider，这导致了 AttributeError。

我们当前采用的临时方案是让每个测试用例自己在 __init__ 中创建 SchemaProvider 实例。这虽然解决了功能问题，但存在代码重复，并且违背了依赖注入的最佳实践。

待实施的重构方案

方案A: 内部逻辑提炼 (中期优化)

这是我们讨论过的、侵入性较小的优化方案。

1. 在 APITestOrchestrator 中创建一个新的私有方法，例如 _initialize_spec_dependent_services(self, parsed_spec)。
2. 此方法负责获取 parsed_spec，设置 self.global_api_spec，并创建所有依赖它的服务（如 SchemaProvider），将实例存放在 self 的属性中。
3. 在 run_tests_from_yapi 和 run_tests_from_swagger 的开头，调用这个新的私有方法。
4. 改造 BaseAPITestCase，使其能够接收注入的 schema_provider 实例。

优点: 实现简单，风险小，能有效减少测试用例中的代码重复。

方案B: 彻底分离业务阶段 (长期目标)

这是更理想、更彻底的重构方案，它将 APITestOrchestrator 的功能进行明确的阶段划分。

1. 重构 APITestOrchestrator 的公共API，将其从一个大而全的 run_tests_from_... 方法，拆分为多个独立的、职责单一的公共方法，例如：

   • load_spec(file_path: str) -> ParsedAPISpec: 只负责加载和解析文件，返回一个解析后的对象。
   • prepare_execution(parsed_spec: ParsedAPISpec): 接收解析后的对象，用它来初始化所有依赖的服务，如 SchemaProvider，并准备好待测试的端点列表。
   • execute() -> TestSummary: 执行所有准备好的测试，并返回最终的摘要。

2. 调整调用流程: run_api_tests.py 中的 main 函数也需要相应调整，以适配这种分阶段的调用方式。

优点:

• 完全符合单一职责原则：每个方法只做一件事。
• 生命周期清晰：数据和依赖的生命周期管理变得非常清晰、可控。
• 高度可测试：可以单独对 load_spec 或 prepare_execution 进行单元测试。
• 更灵活: 未来可以支持更复杂的场景，比如加载多个API规范文件后合并测试。

重构收益

完成上述任一方案（特别是方案B），将使得测试框架的核心代码更加健壮、可维护和可扩展，为未来添加更复杂的功能（如测试依赖、多文件聚合测试等）打下坚实的基础。