# Write Integration Tests for an ASP.NET Core API

Yes. An agent extends WebApplicationFactory tests against real Postgres for your Catalog API, runs dotnet test, and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/write-integration-tests/aspnet-core/), in a Project that has your repository.

## What the agent does

The agent reads the Catalog service and its existing functional test project before adding cases. In a solution like dotnet/eShop it opens `src/Catalog.API/Catalog.API.csproj` and `src/Catalog.API/Apis/CatalogApi.cs`, where versioned route groups map `/api/catalog/items` (paging), `/items/{id:int}`, `/items/by`, `/items/by/{name}`, brand and type filters, facets, and create/update/delete. `global.json` pins the SDK to `10.0.302` with `Microsoft.Testing.Platform` as the test runner.

It inspects `tests/Catalog.FunctionalTests/`. `Catalog.FunctionalTests.csproj` targets `net10.0`, references `Microsoft.AspNetCore.Mvc.Testing`, `Aspire.Hosting.PostgreSQL` and `xunit.v3.mtp-v2`, and project-references Catalog.API. `CatalogApiFixture` subclasses `WebApplicationFactory<Program>`, builds an Aspire `DistributedApplication` with `AddPostgres("CatalogDB").WithImage("ankane/pgvector").WithImageTag("latest")`, and injects `ConnectionStrings:CatalogDB` into the host. Existing tests already cover page size, updates, name search, and some NotFound paths; the agent looks for gaps the prompt names: richer filter combinations, empty pages, and not-found by id that are thin or missing for both API versions 1.0 and 2.0.

New tests stay in the same style: `IClassFixture<CatalogApiFixture>`, `CreateHttpClient` with `ApiVersionHandler` and `QueryStringApiVersionWriter`, and `JsonSerializerDefaults.Web` for `PaginatedItems<CatalogItem>` and `CatalogItem`. Cases hit `/api/catalog/items` with paging bounds, brand/type filter routes from `CatalogApi.cs`, and GETs for missing ids expecting `HttpStatusCode.NotFound`. It does not replace the Aspire Postgres fixture with an in-memory database.

In the sandbox it restores and runs `dotnet test tests/Catalog.FunctionalTests/Catalog.FunctionalTests.csproj` (or the solution filter that includes it) so the real pgvector container starts, then opens a pull request that lists the new theory cases and keeps Catalog.API production code unchanged unless a test harness bug must be fixed.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Write ASP.NET Core integration tests with WebApplicationFactory for the Catalog API's endpoints, against a real Postgres started in the sandbox, covering paging, filters and not found. Run dotnet test and open a pull request.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request that adds or extends test methods under `tests/Catalog.FunctionalTests/` (typically in `CatalogApiTests.cs` or a sibling file), still using `CatalogApiFixture` and the Aspire Postgres resource. Production controllers and EF mappings stay as they were unless the agent had to expose a test seam already used by `Program.Testing.cs`.

The pull request description names the `dotnet test` project path that passed and which routes each new case covers for API versions 1.0 and 2.0. The session trajectory includes restore, container start and test output, so a reviewer can see a red assertion that was fixed before the final push.

Before merging, a reviewer checks that new theories use the same cancellation tokens and JSON options as existing tests, that filter URLs match the live `MapGet` routes, and that the fixture still points at pgvector rather than a different image. Required checks on the pull request should include the Catalog functional test job the repository already runs in CI.

## Run it on every Catalog API route changed

On `pull_request` diffs under `src/Catalog.API/Apis/` or the Catalog test project, have your server POST this session request with the repository in `resources`. Each change gets its own sandbox where Aspire can start Postgres without sharing ports with a developer laptop.

Attach a webhook URL to the API key so Rush notifies `run.completed` with the session URL when the turn ends, and your bot can comment the pull request link on the triggering PR. Respect `max_concurrent` (default 4); queue extra Catalog suites instead of opening overlapping Aspire hosts on one key.

## Why run it on Rush?

WebApplicationFactory plus Aspire Postgres means Docker pulls, port binding and long `dotnet test` runs. On a laptop that blocks other work and fights whatever else is using 5432. Rush gives the agent its own sandbox with Docker, so pgvector starts cleanly, tests run to completion, and your machine stays free.

The result is a reviewable pull request with real HTTP status codes against a real database, not an in-memory stand-in that hides Npgsql or pgvector issues. The trajectory keeps the test host logs, which is what you need when a filter query returns 500 instead of an empty page.

## Frequently asked questions

### Does it use an in-memory database?

No. For an eShop-shaped Catalog project it keeps `CatalogApiFixture`'s Aspire Postgres with the `ankane/pgvector` image, because CatalogContext enables the `vector` extension. Swapping that for EF InMemory would miss the failures this job is meant to catch.

### Will it rewrite my existing CatalogApiTests?

It extends coverage for paging, filters and not-found. It leaves passing theories alone unless a shared helper must change. Everything lands in the pull request diff for review.

### Which .NET SDK does it need?

It follows `global.json`. In eShop that pins `10.0.302` with `rollForward: latestFeature`. The sandbox installs that SDK (or uses an image that already has it) before `dotnet test`.

### How are API versions handled?

The same way the existing tests do: `[InlineData(1.0)]` and `[InlineData(2.0)]` with `ApiVersionHandler` and query-string versioning, because Catalog maps separate v1 and v2 route groups for several items endpoints.