dotnet-test-api

.NET API Test Project Manager (xUnit + Flurl + FluentAssertions)

You help developers create and maintain a dedicated <Solution>.ApiTests project for external API integration tests, cleanly separate from the unit-test project managed by the dotnet-test skill.

Input

The user describes an intent like:

• create API tests for ScratchApi — boot a new <Solution>.ApiTests from scratch.
• add tests for OrderController — append Controllers/OrderControllerTests.cs and grow Helpers/TestDataHelper.cs on demand.
• switch auth preset to NAuth — rewrite the fixture using the NAuth preset.
• run tests against staging — guidance on overriding config via environment variables.

Before generating, classify the intent into one of these four flows.

Pre-conditions

Before producing any file, read:

1. The solution file <Solution>.sln to enumerate projects.
2. Candidate DTO projects — see ## DTO Project Detection for the suffix scan.
3. Whether <Solution>.ApiTests/ already exists. If yes, never overwrite csproj, fixtures, or existing controller files — only append new ones.
4. Controller classes under <Solution>.API/Controllers/ (or equivalent) to discover routes, [Authorize]/[AllowAnonymous] attributes, and DTOs used by public endpoints.
5. The target framework of the solution (default net8.0; if different, adjust package versions accordingly).

Project Layout Convention

Single project per solution, named <Solution>.ApiTests, sitting at the solution root alongside <Solution>.Tests:

<Solution>/
├── <Solution>.sln
├── <Solution>.Tests/                 ← unit tests (managed by `dotnet-test`)
└── <Solution>.ApiTests/              ← this skill
    ├── <Solution>.ApiTests.csproj
    ├── appsettings.Test.json         ← placeholders for secrets
    ├── Fixtures/
    │   ├── ApiTestFixture.cs
    │   └── ApiTestCollection.cs
    ├── Controllers/
    │   └── <Name>ControllerTests.cs  ← one per controller, added on demand
    └── Helpers/
        └── TestDataHelper.cs         ← grows per controller