Fix ThemeDB initialization in tests #81305
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While working on another PR I ran into issues with tests because of how we work with
ThemeDB
in tests. Basically, each test cases initializes its ownThemeDB
instance, which overrides the singleton pointer. This means that interactions with the singleton instance become unreliable. It doesn't cause any visible problems at the moment, but it does with my PR, because I needControl
andWindow
classes to statically interact with the singleton.So I'm fixing that, and also slightly changing the order of initialization for
ThemeDB
. Now it's initialized before scene types, so that they can work with it. I also added an explicit way to finalize default resources inThemeDB
, which is needed for test cases which destroy and recreate the theme constantly.Unfortunately, we have to do it this way, because test cases also create and destroy the
RenderingServer
instance, which themes need for textures to work. Otherwise I'd just use the singleton.Also noticed that
Viewport
andWindow
tests used the same name for the registered class, causing a warning fromClassDB
when running tests. So fixed that as well.