# Backend Tests

## Scope

These rules apply to everything under `backend/tests/`.

## Test Framework

- Use `xUnit` everywhere.
- Use `[Fact]` for single-case tests and `[Theory]` with `[InlineData(...)]` for parameterized tests.

## Assertions

- Prefer native `Xunit.Assert` for new tests.
- Keep assertions direct and readable.
- Assert the behavior that matters most: output, persisted state, ordering, filtering, and errors.

## Test Design

- Follow `Arrange / Act / Assert`.
- Prefer one clear behavior per test.
- Use descriptive test names in the form `Method_Scenario_ExpectedResult`.
- Keep test setup minimal; extract helpers only when reused.

## Isolation

- Tests must be deterministic and independent.
- Do not rely on execution order.
- For API/data tests, keep per-test isolation through the provided schema/fixture infrastructure.
- Do not share mutable state between tests unless it is explicitly managed by an xUnit fixture.

## Infrastructure

- Reuse existing test infrastructure in `Infrastructure/` before adding new helpers.
- For `Kds.Ai.ApiService.Tests`, use the shared PostgreSQL/Testcontainers fixture pattern already present.
- If a test requires Docker/Testcontainers, make that dependency explicit and keep the test focused.

## Verification

- Run tests with `dotnet test --project <path-to-test-csproj>`.
- Prefer validating one backend test project at a time.
- After test changes, run the relevant `dotnet test --project ...` command.
- If backend code was changed together with tests, finish with a solution build when possible.
- Do not run `dotnet build` and `dotnet test` at the same time for overlapping backend projects.
- Do not run multiple build/test commands in parallel against the same project outputs because file locks can cause false failures.