description	alwaysApply
Unit vs integration tests; integration when data persistence/mutation exists; C# xUnit; Godot manual until harness.	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.

Until the project adopts a harness (GUT, Godot unit tests, or CI export checks), rely on manual verification for gameplay and scene changes.
For non-trivial client work, note how you verified (steps or scenario) in the PR or story plan so reviewers can repeat it.

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.