refactor tests that depend(ed) on the Config enum being functional
- 主要语言
- Java
- 星标
- 3.1k
- 派生
- 1.4k
- 平均合并
- 6 天 19 小时
- 30 天内合并 PR
- 32
描述
some tests explicitely call on members of the Config enum to perform tests. refactor those tests so the enum can be phased out itself.
> 2. Tests that mock ConfigurationDao.getValue(...) directly, where switching the production code to .value() would make the mock inert (since .value() reads from the static ConfigDepot, not the injected DAO):
> - ApiRateLimitServiceImpl.java's ApiLimitEnabled/ApiLimitInterval/ApiLimitMax/ApiLimitCacheSize reads — ApiRateLimitTest.java mocks these with a value ("true" for enabled) that diverges from the ConfigKey defaults, so skipping here isn't optional.
> - FirstFitPlanner.java's ImplicitHostTags read — FirstFitPlannerTest.java mocks it to "GPU", which also diverges from default.
> - ScaleIOPrimaryDataStoreDriver.java's MigrateWait read — deferred out of caution: ScaleIOPrimaryDataStoreDriverTest.java mocks it, and since ConfigKey's depot state is a static field, there's cross-test-pollution risk from other test classes (e.g. FirstFitPlannerTest) calling ConfigKey.init() in the same Surefire fork — not something to resolve with a coincidental "the mocked value happens to match the default" argument.
> - (ConfigurationManagerTest.java's ControlCidr and ActionEventUtilsTest/ActionEventInterceptorTest's PublishActionEvent were also mocked directly, but their mocked values matched the ConfigKey defaults exactly, so those were judged safe to migrate rather than deferred.)
贡献指南
评估
这个 Issue 还没有评估数据。