Testing APIAPI's Interaction Kit

Run the kit's own automation suite in your project.

Assumes you have finished quick-start.

What ships

The kit ships its own automation suite in the UKInteractionTests module (UncookedOnly, so it is never compiled into a cooked game, client or server target). You can run it against your own project to verify the kit behaves as documented in your engine version and configuration.

Running it is safe: the suite leaves your project byte-identical. See Your settings are left untouched.

Running the suite

Every kit test name begins with UK.Interaction., followed by the owning module segment (Core., Client., Debug., Editor., GAS., CommonUI.), so one command runs the whole suite:

UnrealEditor-Cmd <YourProject>.uproject -nullrhi -unattended -nosplash
    -ExecCmds="Automation RunTests UK.Interaction; Quit"

In the editor, the same tests appear under Tools → Session Frontend → Automation.

Expect the run to be green on any supported engine, in the demo project or your own, in well under 20 minutes. Some tests will report that they were skipped — that is the designed behaviour, not a problem. The next two sections explain which ones, and why.

The three partitions

The suite is partitioned by what a test depends on. The partition is visible in the test name.

Partition	Name shape	What it asserts	In your project
Behavior	everything else	Behaviour only — "does the kit do the right thing"	Always runs.
Calibration	`UK.Interaction.<M>.Calibration.*`	Exact cycle counts, byte layouts, tick order	Runs when your configuration matches the kit's pinned one; otherwise skips.
Gate	`UK.Interaction.<M>.Gate.*`	The kit's own internal release gates	Always skips in your project — see below.

Why Gate tests skip for you. Gate tests read internal fixture files that are deliberately not shipped in the Fab archive. They check things that only matter to us before we publish — descriptor invariants, CI lane tables, coverage ledgers. In your project there is nothing for them to check, so they report:

UK.Interaction.<M>.Gate.*: skipped — repo fixtures not found (internal release gate)

That line is the correct, expected outcome. A Gate test that fails instead of skipping is a bug in the kit — please report it.

Why Calibration tests may skip. These assert numbers that are only meaningful under a specific configuration (fixed time step, seeded RNG, pinned networking cvars, a specific replication path). If your project resolves a different configuration, the number would be wrong for reasons that have nothing to do with the kit's correctness, so the test skips rather than reporting a false failure.

At the end of a run the suite prints one line of counts — how many tests ran and how many skipped, per partition and per reason. The skips are never silent.

Skip reasons

Every skip names exactly one reason from this closed list, emitted as UK_SKIP_REASON=<reason>.

Reason	Meaning	What, if anything, you should do
`fixture_missing`	A `Gate` test needed the kit's internal fixtures, which do not ship.	Nothing — expected in every customer project.
`session_unavailable`	The test needs an in-process networked session, and this run has no editor (`-game` / `-server`).	Nothing — run the suite in the editor (or `UnrealEditor-Cmd`) to include these.
`content_missing`	The test needs a map or preset from `Content/UKInteraction/Tests/`, and that folder is not installed.	Nothing, if you removed the test content on purpose. Reinstall it to include these tests.
`calibration_mismatch`	The resolved configuration differs from the one the number was calibrated against.	Nothing — the behavioural coverage still ran.
`iris_legacy_only`	Iris replication is enabled, and this test measures the legacy replication path specifically.	Nothing — the kit supports both paths; only this measurement is path-specific.
`adapter_inactive`	The test covers an optional adapter (for example GAS or CommonUI) that is not enabled in your project.	Nothing, unless you expected that adapter to be active.
`tier_gated`	The test belongs to a maturity tier above the one this run executes.	Nothing.
`fallback_multiprocess`	This engine version could not host an in-process session, so the test belongs to the kit's separate multi-process runner.	Nothing.

Your settings are left untouched

The networked tests must pin process-wide state to be deterministic — fixed time step, RNG seeds, several net.* console variables, a test net driver. All of it is snapshotted before the suite touches anything and restored afterwards by a single RAII object, plus a shutdown guard that restores even if the editor is closed mid-run.

Concretely, after a suite run:

Config/DefaultEngine.ini and Config/DefaultEditorPerProjectUserSettings.ini in your project are byte-identical to what they were before — the kit never writes to them,
every console variable the suite touched is back at the value it had,
the kit's own Config/*.ini files are unchanged.

The kit asserts this on itself: it hashes those files and dumps those variables before and after every run and fails if a single byte moved. If you ever see the suite change a setting in your project, that is a bug of the highest severity — please report it.

Test kinds

Kind	Where	What it covers
Spec tests	`Source/UKInteractionTests/Private/<Area>/*.spec.cpp`	logic: state machines, formulas, validation
Functional tests	demo maps under `Content/UKInteraction/Tests/`	integration in a running world
Networked functional tests	the same, under listen-server and dedicated-server PIE	replication, join-in-progress, ownership

If your "cook everything" reaches the kit's `Tests/` content

The kit's functional-test maps live under Content/UKInteraction/Tests/, and the kit never puts that folder in a cook list: the plugin's DirectoriesToAlwaysCook names exactly three folders — Client/, Core/Detection/ and Core/Presets/ — because those three hold assets your project reaches only through a soft path in the kit's settings, which the cooker cannot follow on its own. Core/Maps/, Core/Demo/ and Tests/ are never in that list.

If your project cooks everything — a DirectoriesToAlwaysCook entry that covers the plugin, or a "cook all content" switch — the test maps can be pulled into your package anyway. That is dead bytes, not an error. The maps load nothing at runtime unless something opens them, and nothing in a shipped game does; the only cost is package size (single-digit MB). It is not a bug report, and the kit does not gate on it, because what your project chooses to cook is your project's decision. If you want them gone, add /UKInteraction/UKInteraction/Tests to your project's Directories to never cook (Project Settings → Packaging), which takes precedence.

One thing you will not see from those maps is a missing-class failure in a Shipping build: the functional-test actors they contain come from a developer-only engine module, so the kit keeps them out of every customer-cookable map by construction. The demo map ships with zero of them.

Structural gates

Some of the kit's guarantees are checked without an engine at all — descriptor invariants, per-module dependency ceilings, forbidden tokens. Those checks run before every release as part of the kit's own build pipeline and are not part of the shipped archive, like the Gate partition above.

Reporting a failure

A failing kit test is a bug report we want. Include:

engine version and hotfix, platform, and build configuration,
the full test name,
the UK_FAIL_CLASS=<class> token on the failure line — every kit failure carries one, and it tells us immediately what kind of failure it was (assertion, timeout, leak, budget, session_start_timeout, measurement_invalid, infrastructure, …),
the log excerpt containing the LogUKInteraction* / LogUKHarness lines around the failure,
the printed partition/skip counts line from the end of the run.

A skip is not a failure and does not need reporting. A Gate test that fails rather than skips, or any change to your project's settings, always does.