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 with this body:
{
"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"
}
]
}- 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.
- 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.
- 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.
The use case this job follows, with its automation and trigger: Write the missing tests.
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.