Class SettingsUiTests

Namespace

GrindFest

Assembly

GrindFest.dll

Player-like tests for the Settings panel and the ESC/menu flow.

Why these exist: a UI rewrite (e.g. the planned OneJS upgrade) can break the UI in ways nothing else catches - see the note on the ESC test below. Clicks go through real UI Toolkit events (L2, see Ui.cs); only ESC is invoked directly, because PlayerInput reads ESC from the legacy Input Manager and UI events never feed that.

The UI helpers (ClickText, ClickTextWithin, WaitForText, AssertTextVisible, PressEscape, ...) live on DevTest so every test can use them.

public class SettingsUiTests : DevTest

Inheritance

object

DevTest

SettingsUiTests

Inherited Members

DevTest.Name

DevTest.Passed

DevTest.Failed

DevTest.Skipped

DevTest.FailureReason

DevTest.ExpectedLogErrors

DevTest.ProbeMainMenu(string[])

DevTest.SpawnItem(string, int, ItemRank, int)

DevTest.SpawnProp(string)

DevTest.LoadAsset<T>(string, Action<T>, AssetTier)

DevTest.WaitForStableGroundAt(Vector3, int, float)

DevTest.PlaceItemOnGroundWhenReady(ItemBehaviour, Vector3, string, float)

DevTest.PlaceItemOnGround(ItemBehaviour, Vector3, string)

DevTest.AcquireMonster(params string[])

DevTest.SpawnMonster(string, int, MonsterRank, float)

DevTest.HeroPosition

DevTest.Hero

DevTest.BotHero

DevTest.TrackForCleanup(GameObject)

DevTest.RequireRuntimeCompilation()

DevTest.GiveSkill<T>()

DevTest.GiveItemToHero(ItemBehaviour)

DevTest.IsTerrainReadyAt(Vector3)

DevTest.TryGetGroundPoint(Vector3, out Vector3, Transform)

DevTest.TryGetTerrainPoint(Vector3, out Vector3, Transform)

DevTest.TryGetClearGround(Vector3, out Vector3, out string, Transform)

DevTest.DescribeGroundBelow(Vector3, Transform)

DevTest.WaitForTerrainAt(Vector3, float, bool)

DevTest.WaitForTerrain(float, bool)

DevTest.IsNavMeshReadyAt(Vector3)

DevTest.WaitForNavMeshAt(Vector3, float, bool)

DevTest.DoAction(string, Func<ActionResult>, float)

DevTest.LastActionResult

DevTest.TryDoAction(Func<ActionResult>, float)

DevTest.WaitUntil(string, Func<bool>, float, Func<string>)

DevTest.Cleanup()

DevTest.EnsureContentLoaded()

DevTest.Assert(bool, string)

DevTest.AssertEqual<T>(T, T, string)

DevTest.AssertNull(object, string)

DevTest.AssertNotNull(object, string)

DevTest.AssertGreaterThan(float, float, string)

DevTest.UiRoot

DevTest.ClickText(string)

DevTest.ClickTextWithin(string, string)

DevTest.ClickById(string)

DevTest.IsTextVisible(string)

DevTest.VisibleTextsDescription()

DevTest.WaitForText(string, float)

DevTest.WaitForTextGone(string, float)

DevTest.AssertTextVisible(string)

DevTest.AssertTextNotVisible(string)

DevTest.PressEscape()

DevTest.PressEscapeAndWait(float)

DevTest.IsPanelOpen(string)

DevTest.WaitForPanel(string, bool, float)

DevTest.CloseAllPanels()

DevTest.DescribePanelRect(string)

DevTest.AssertPanelOnScreen(string)

DevTest.WaitForPanelOnScreen(string, float)

DevTest.AssertPanelClosed(string)

DevTest.EvalUi(string)

DevTest.TryWaitUntil(Func<bool>, float)

DevTest.OpenMainMenu(float, int)

DevTest.GetLiquidAmount(LiquidContainerBehaviour, ResourceType)

DevTest.GetTotalLiquid(LiquidContainerBehaviour)

DevTest.Log(string)

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.

Methods

Escape_AfterVisitingSoundTab_MenuStillReopens()

TEMPORARY REGRESSION TEST - delete this once the OneJS upgrade is in and this flow is verified.

It guards a constraint rather than a feature: the QuickJS backend currently in use gives JS a call stack of only ~90 frames, so re-rendering the Settings panel while the Sound tab was active overflowed it, aborted the state update, and left the ESC menu dead for the rest of the session (2026-09-13). A newer OneJS (or a backend with a normal stack) removes that constraint, and then there is nothing left here to protect - Menu_SettingsButton_... above still covers the behaviour a player actually cares about.

Menu_SettingsButton_OpensPanelAndSwitchesTabs()

A player opens the menu with ESC, clicks Settings, then clicks the Sound tab. The tab content must actually render - clicking a tab is what used to overflow the JS stack and poison every later re-render.