czy006 commented on PR #4004: URL: https://github.com/apache/amoro/pull/4004#issuecomment-3649092842
> 我注意到 amoro-format-iceberg 模块中的一些测试失败，并出现以下错误： > > 构造函数 [public org.apache.amoro.formats.TestIcebergAmoroCatalog(org.apache.amoro.formats.AmoroCatalogTestHelper)] 中，参数 [org.apache.amoro.formats.AmoroCatalogTestHelper arg0] 没有注册 ParameterResolver。 > > TestMixedIcebergFormatCatalog 中的几个测试方法出现类似错误，导致 amoro-format-iceberg 模块测试失败，后续模块被跳过。 > > 我的理解是，在 JUnit 4 中，AmoroCatalogTestHelper 很可能是通过自定义运行器、规则或测试实用程序注入的，但在迁移到 JUnit 5 之后，没有为该辅助程序配置 ParameterResolver（或等效机制）。 > > 在进行进一步修改之前，我想请教一下本项目的最佳方案： > > 我是否应该引入 JUnit 5 ParameterResolver（并通过以下方式注册它）？@ExtendWith或者服务加载器）提供 AmoroCatalogTestHelper？ > > 或者您是否更倾向于重构这些测试，以避免构造函数注入，并使用与此存储库中现有的 JUnit 5 测试更一致的其他模式？ > > 一旦我知道最佳方向，我就可以相应地更新测试。 > I noticed that some tests in the amoro-format-iceberg module are failing with the following error: > > No ParameterResolver registered for parameter [org.apache.amoro.formats.AmoroCatalogTestHelper arg0] in constructor [public org.apache.amoro.formats.TestIcebergAmoroCatalog(org.apache.amoro.formats.AmoroCatalogTestHelper)]. > > Similar errors occur for several test methods in TestMixedIcebergFormatCatalog, which causes the amoro-format-iceberg module tests to fail and the subsequent modules to be skipped. > > My understanding is that, in JUnit 4, AmoroCatalogTestHelper was likely injected via a custom runner, rule, or test utility, but after migrating to JUnit 5 there is no ParameterResolver (or equivalent mechanism) configured for this helper. > > Before making further changes, I would like to ask for guidance on the preferred approach in this project: > > Should I introduce a JUnit 5 ParameterResolver (and register it via @ExtendWith or the service loader) to provide AmoroCatalogTestHelper? > > Or would you prefer to refactor these tests to avoid constructor injection and use another pattern that is more consistent with the existing JUnit 5 tests in this repository? > > Once I know the preferred direction, I can update the tests accordingly. If it were me, I would prefer to refactor it. It seems that Junit5 has made some new incompatible changes to ParameterResolver, so it's also feasible for us to achieve equivalent effects in a new way cc @Jungkihong07 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
