Class UiReloadTests
- Namespace
- GrindFest
- Assembly
- GrindFest.dll
A UI reload must not cost the session its menu.
This guards a mechanism rather than a feature, because that mechanism is what makes two other tests red:
ModManager.RefreshAndReload() ends with _uiModDirty = true, so ANY mod refresh - a player
subscribing one, or a DevTest calling it - tears the OneJS UI down and re-evaluates app.js in the
middle of a session.
Measured 2026-09-16: a full suite run in which that happens logs TWO [index.tsx] ... Initializing
lines instead of one, and SettingsUiTests - both of them, the ESC one and the Settings-button one -
fail from that point on with "main menu never opened after 6 ESC attempts". The same two tests pass in a
session where nothing refreshed the UI (2 passed in 5,2 s), and they passed in every suite run before the
reload happened twice. So the reload is the cause, and this is the smallest reproduction of it: open the
menu, reload the UI, open the menu again.
public class UiReloadTests : DevTest- Inheritance
-
objectUiReloadTests
- Inherited Members
Properties
- NeedsFreshUi
True for a test that reads the OneJS UI, which makes the runner reload the whole UI before it. That reload is the only reset that reaches the state a panel keeps while it stays mounted but hidden - the Character screen's selected tab, for instance, which made two CharacterScreenUiTests fail with "Timeout waiting for 'Strength' visible" after the tab had been picked by hand before the run.
Opt-in because it is not free: measured 2026-09-16, reloading before every test left 888 s of a 1194 s suite outside the test bodies (against 119 s in the 358 s run without it), roughly 8,5 s per test. Only the tests that actually read the UI pay that.