Skip to content

Verification Harness

gokuthug1 edited this page Oct 5, 2026 · 1 revision

Verification Harness

GokuTrap has a self-contained automated check suite. It needs no test framework, no network access, and no Roblox installation.

Running it

dotnet run --project tests/GokuTrap.FeatureChecks -c Release -- .

Expected result: PASS 69 checks and exit code 0.

Pass the repository root as the argument. On Windows, run it in a terminal with a desktop runtime installed.

CI runs the identical command, so a green local run and a green CI run mean the same thing. See Release-Process.

What it guarantees

Guarantee How
Never launches Roblox No Roblox process is started
Never signs in No authentication flow is triggered
Never touches your real installation Paths is initialised to a temporary scratch directory
Never downloads an update Network-dependent operations are exercised against controlled inputs, not live services
Exercises real WPF It instantiates actual pages and windows, not mocks
Exercises real native windows Overlay window styles are checked on real Win32 window handles

What the 69 checks cover

Settings and migration

  • Defaults applied on a missing settings file
  • Migration from an older or partial file
  • Null collection safety
  • Range clamping for overlay size, opacity, offsets and update interval
  • Unknown enum values falling back to safe defaults
  • Stale account validation status being cleared on load
  • Avatar URLs cleared unless HTTPS and *.rbxcdn.com

Community Hub catalog

  • Malformed JSON rejected
  • Duplicate preset and flag keys rejected
  • Oversize payloads rejected
  • Bounded streamed read with a size cap
  • Redirect host and scheme validation
  • Only allowlisted flags accepted
  • Idempotent apply
  • Conflict-aware revert preserving later manual edits

Updater

  • Release tag, asset, digest and PE validation
  • Unsafe URLs failing
  • Version comparison ignoring omitted trailing zeros
  • Atomic replacement preserving exact backup bytes
  • Failed-handoff lock cleanup independent of progress
  • Download cancellation leaving the installation intact

Sound packs

  • Local asset ownership checks
  • Path traversal rejection
  • Header and size validation
  • Conflicting mods preserved rather than overwritten

Radar

  • Truthful "unavailable / not measured" states
  • Stale candidate reporting
  • Place context re-verification before handoff
  • Rate-limit cooldown behaviour

Saiyan Mode

  • Non-Player processes rejected
  • PID and path verification
  • Windows default performing no writes
  • Priority-only management never touching affinity
  • Only changed fields restored
  • Exited-process journals pruned

Runtime reload

  • Settings reload updates only runtime controls
  • Unrelated in-memory settings are not replaced
  • Local validation failures surface localized, actionable messages

Real WPF UI

  • All seven feature-tool tabs present in an actual WPF page
  • Each tab has a localized accessible title
  • No WPF binding errors
  • Diff bound to an actual list control
  • Async memory command completing and reporting an honest empty state
  • UI preset selection generating a diff
  • AutomationPeer invocation of a real button

Overlay

  • The actual window is click-through and non-activating
  • Modifier + key hotkeys accepted
  • Gameplay single-key and modifier-only hotkeys rejected

Credentials

  • Test diagnostics contain no credential material

Why the count matters

The count is a floor, not a target. A pull request that reduces the number of passing checks has removed coverage, even if the suite still exits 0.

Do not achieve a green run by deleting a check, weakening an assertion, catching and swallowing an error, or adding a suppression. The suite exists to make an unsafe change fail loudly — see Contributing.

Environment-dependent output

One check reports the machine's CPU topology, for example:

Windows CPU topology: 8 logical CPUs, 4 cores, 1 groups. OS topology available; no distinct efficiency classes. Automatic performance-core selection unavailable.

That text differs per machine and is not a failure. The check passes because the reported state is truthful. On a machine with distinct efficiency classes, automatic faster-core selection becomes available and the message changes accordingly.

What the harness does not cover

Some behaviour genuinely cannot be verified without a real Roblox session. These are tracked as manual acceptance items in docs/FEATURE_DELIVERY.md:

  • real process policy application and restoration on a live Player
  • official sign-in and session revocation
  • server hop success
  • audio playback and format decoding in a real client
  • overlay positioning on mixed-DPI and negative-origin monitors
  • behaviour in exclusive fullscreen
  • a real release download, upgrade and rollback install

Automation has verified the logic, the file handling, the integrity checks and the actual WPF controls. It has not verified those live-game behaviours, and this wiki does not claim otherwise.

Clone this wiki locally