refactor tests that depend(ed) on the Config enum being functional
- Lingua principale
- Java
- Stelle
- 3.1k
- Fork
- 1.4k
- Merge medio
- 6g 19h
- PR unite (30g)
- 32
Descrizione
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.)
Guida per i contributori
Apri la guida per i contributori
Valutazione
Questa issue non è ancora stata valutata.