description	alwaysApply
Unit vs integration tests; integration when data persistence/mutation exists; C# xUnit; Godot client unit tests with script changes (NEON-14 harness + gdscript.yml CI).	true

Testing expectations (Neon Sprawl)

C# server

Non-trivial logic (validation, simulation rules, serialization boundaries, idempotency, security-sensitive paths) should have automated tests once a test project exists in the repo.
Default framework: xUnit for new test projects unless the repo already standardizes on something else—stay consistent with existing *.Tests projects.
Layout: use Arrange / Act / Assert in every test method; see C# style — Unit and integration tests.
Names: MethodName_ShouldExpectedOutcome_WhenScenario; see C# style — Test method naming convention.
No test project yet: It is acceptable to ship a small change without a suite only while the server is mostly scaffolding. When you add the first testable module, add a NeonSprawl.Server.Tests (or equivalent) project and start covering that area; do not leave new core logic permanently untested.
Bug fixes: Prefer a regression test when the fix is non-obvious or has broken before.

Once the server reads or writes durable state (e.g. PostgreSQL via EF Core, Dapper, or similar; migrations; transactional inventory/progression/economy paths), expect integration tests that exercise the real persistence boundary, not only mocked repositories.
Cover at least: happy path, constraints / failures (unique keys, FKs, expected rollbacks), and idempotent or retry-safe behavior where the design requires it.
How to run them: Prefer a project-standard approach (dedicated test database, Testcontainers, or CI service container) documented in server/ README or docs/—do not leave integration tests machine-only without notes.
Spike exception: A story may defer integration tests only when persistence is explicitly out of scope; call that out in the plan and add tests when data manipulation lands.

Harness (NEON-14): GdUnit4 lives under client/addons/gdUnit4/; suites under client/test/. client/README.md documents local and headless runs; .github/workflows/gdscript.yml runs gdlint, gdformat, and headless GdUnit when client/scripts/, client/test/, client/addons/, or client/project.godot change.
Production script changes: Any PR that adds or changes GDScript under client/scripts/ (and any other application .gd outside client/addons/ and client/test/) must add or update tests under client/test/ in the same change set. If a change is not reasonably testable, say so in the PR (or story plan) with a short reason—do not skip tests silently.
Scenes / assets / manual checks: Scene tweaks, visuals, and flows that unit tests do not cover still deserve manual verification notes in the PR when behavior could regress.

If CI is added later, treat its required steps (e.g. dotnet test, schema validation) as gates: fix failures or update workflows/docs intentionally—do not silence checks without a recorded reason.
When a story is explicitly client-only or spike (no server), match that scope in tests too (manual client checks only), and call out temporariness per architecture authority.