Glue Live Game Testing

Glue Live Game Testing

GameCommunicationPlugin/GlueControl/Embedded/*.cs (CommandReceiver, GlueControlManager, EditingManager, ...) is <Compile Remove>d from GameCommunicationPlugin.csproj — it only exists inside a compiled, running game process, never inside Glue itself. glue-unit-test-bootstrap's GoldProjectCompileTests prove that closure compiles; they never run it. If a bug is in what CommandReceiver.HandleDto actually does at runtime (screen transitions, entity selection, edit-mode state), a compile-only test cannot catch it — you need a real running game process.

The harness

GlueUnitTests/TestSupport/LiveGameProcess.cs builds a gold project, launches its real built .exe, and drives it through Glue's actual CommandSender/GameJsonCommunicationPlugin.Common.GameConnectionManager socket protocol — the same wire protocol production Glue uses, not a stand-in.

[Trait("Category", "LiveGame")]
[StaFact]
public async Task MyTest()
{
    GlueTestBootstrap.EnsureGameProjectPluginsRegistered();
    using var game = await LiveGameProcess.StartAsync(
        "Samples/EditorTest1",
        csprojRelativeToProjectRoot: "EditorTest1/EditorTest1.csproj",
        exeRelativeToProjectRoot: "EditorTest1/bin/Debug/net9.0/EditorTest1.exe");

    var screenName = await game.GetCurrentScreenName();   // "" if no screen loaded
    var response = await game.SelectEntity("Entities\\Entity1");
}

StartAsync (default refreshLiveEditCodeFromSource: true) loads the copied project into Glue and calls GoldProject.EmbedLiveEditCode() before building, so the test exercises the CURRENT branch's Embedded/*.cs, not whatever was checked in. See LiveGameProcessTests.cs for worked examples.

The afterBuildBeforeLaunch hook changes the project after the build, for tests where the running game is behind Glue (see EditorTest1_SharedVariableChangedAfterBuild_IsAppliedByConnectSweep).

Adding a new drive/observe method

Follow GetCurrentScreenName()/SelectEntity(): build the real DTO (GameCommunicationPlugin.GlueControl.Dtos) and call CommandSender.Self.Send(dto) directly.

Landmine — do not set GlueState.Self.CurrentEntitySave/CurrentScreenSave/CurrentNamedObjectSave to drive selection. Their setters route through GlueState.Find.TreeNodeByTag(value), which needs a real, populated WPF tree view. There isn't one in this headless host, so the assignment silently no-ops (CurrentElement stays null) and RefreshManager.PushGlueSelectionToGame sends nothing — no exception, no signal, just a test that mysteriously never sees the effect. Skip Glue's UI-bound selection state entirely and build the DTO by hand.

Only Samples/EditorTest1 works as a target project today

LiveGameProcess needs a project whose Game1.Generated.cs already constructs GlueControlManager/GameConnectionManager — i.e. one that went through a real "enable live edit" Glue session. That wiring comes from MainCompilerPlugin.HandleGluxLoaded (Game1GlueControlGenerator), and MainCompilerPlugin cannot run in the test host (it builds real WPF tabs and opens sockets on registration — same reason GoldProject.EmbedLiveEditCode() calls EmbeddedCodeManager.EmbedAll directly instead of going through it). So Game1.Generated.cs can't be regenerated headlessly; LiveGameProcess preserves it exactly as checked in (only patching its port) rather than deleting/regenerating it.

Samples/EditorTest1 is checked in with its Generated.cs committed - a .gitignore exception like BeefballKni's, since *.Generated.cs is gitignored repo-wide otherwise. To add another target project: turn on live edit for real in a real Glue session, copy the project in the same way (exclude bin/obj, keep the sibling .sln - ProjectLoader needs it), add the same two-line .gitignore exception.