Unity-NPC-Szenariotests

Reproducible NPC Scenario Tests

Inspect Unity Test Framework version, test assemblies, NPC architecture and available Editor/player tooling. Name the bug or behavior contract before choosing a test layer.

• Test pure decision/scoring rules in EditMode with controlled facts, clock, random source and stable candidate ordering. Cover impossible choices, thresholds, ties, memory expiry and cancellation without constructing an unnecessary scene.
• Use PlayMode for real sensors, physics, NavMesh, animation/lifecycle and scene transitions. Build a small arena with explicit geometry, layers, baked/runtime navigation and owned test actors; verify setup before interpreting a behavior failure.
• Assert transitions and bounded outcomes, not arbitrary render-frame sleeps. A path request can be pending; observe completion/failure with a timeout and include a decision/path trace on failure.
• Distinguish a reproducible scenario from deterministic Unity physics. Record seed, timestep, package versions, initial state and player input; do not promise identical cross-platform trajectories merely because the seed matches.
• Test target destruction, occlusion, unreachable destinations, interrupted actions, pooled reuse and repeated scene load. Restore global time/random/physics settings and clean up actors, assets and subscriptions after each test.
• For crowd performance, fix scene, actor count, camera, build/backend and warm-up. Use supported profiler/performance-test tooling; compare distributions/worst-frame spikes and allocations rather than a single Editor frame.

Run only checks supported by the current environment and task. Report EditMode, PlayMode and player results separately, preserve failure output and identify behavior that still requires human playtesting. Never reuse upstream example measurements as this project's results.

Reference: version-matched Unity Test Framework. No upstream test helper scripts are assumed installed.