Runtime Verification

When to use runtime verification

Use it after there is a behavior worth observing: reproducing a reported bug, checking a bounded mechanic, or confirming that a change produced a named outcome. File edits and compilation can be useful prerequisites, but neither establishes runtime behavior.

Available evidence

• Runtime controls and session state supported by the active engine integration.
• Evidence such as traces, watches, signals, logs, screenshots, selected runtime values, and relevant engine output.
• Input used to exercise a bounded condition.
• Engine errors and visible outcomes that help interpret the run.

Verification loop

1. State the expected behavior precisely.
2. Allow any relevant compilation, import, or project update to complete before running the behavior.
3. Run the game or target scene when the question requires it.
4. Exercise the behavior and collect only the evidence needed for that condition.
5. Confirm that the observation itself was valid before interpreting a quiet result.
6. Review the evidence beside the final diff and decide whether more testing is needed.

Unity and Godot differ

Unity provides runtime work through Play Mode and its editor integration. Godot combines editor actions with a managed runtime probe. The controls and evidence are not assumed to be identical across engines.

Not reproduced is a valid result

Verification does not have to end with a patch. When the requested behavior cannot be reproduced with valid observed evidence, the correct outcome can be to report that boundary and make no intentional change rather than inventing a fix.

Limitations

Bounded runtime evidence is not autonomous QA and does not guarantee global correctness. It does not by itself establish game feel, visual quality, accessibility, edge-case coverage, performance across conditions, or platform-specific correctness. The developer decides whether the evidence is sufficient.

Product overview

Related documentation