feat: add built-in HTTP response assertions

[thomhurst]

Summary

• Adds 16 built-in HttpResponseMessage assertions to TUnit.Assertions so users don't need to create their own for common HTTP integration testing patterns
• Removes the 7 custom assertions from the CloudShop example that are now built-in, validating the feature solves the original problem
• Adds 18 unit tests covering all new assertions

Closes #4769

New assertions

Category	Assertions
Specific status codes	IsOk(), IsCreated(), IsNoContent(), IsBadRequest(), IsUnauthorized(), IsForbidden(), IsNotFound(), IsConflict()
Parameterized	HasStatusCode(HttpStatusCode)
Range checks	IsRedirectStatusCode(), IsClientErrorStatusCode(), IsServerErrorStatusCode()
Content	HasJsonContent(), HasContentType(string)
Headers	HasHeader(string) — checks both response and content headers

Usage

// Before: manual status code checks or custom [GenerateAssertion] per project
await Assert.That(response.StatusCode).IsEqualTo(HttpStatusCode.Created);
await Assert.That(response.IsSuccessStatusCode).IsTrue();

// After: built-in fluent assertions
await Assert.That(response).IsCreated();
await Assert.That(response).IsSuccessStatusCode();
await Assert.That(response).HasJsonContent();
await Assert.That(response).HasHeader("X-Request-Id");

Note on CloudShop example

The CloudShop example's CloudShop.Tests.csproj was changed from a NuGet PackageReference to a ProjectReference so it can use the new built-in assertions before the next release. This should be reverted back to a PackageReference when the next TUnit version is published.

Test plan

• All 18 HttpResponseMessageAssertionTests pass
• Existing HttpStatusCodeAssertionTests still pass (7/7)
• TUnit.Assertions.Tests builds with 0 errors
• CloudShop example builds with 0 errors using built-in assertions
• CI passes

🤖 Generated with Claude Code

[claude]

Code review

This PR adds excellent HTTP response assertions that will be very useful! The implementation follows TUnit patterns well and the test coverage is comprehensive.

However, there's one blocking issue that needs to be addressed before merging:

Missing Snapshot Tests

Issue: The PR adds 14 new methods with [GenerateAssertion] attributes but doesn't include the required snapshot tests.

CLAUDE.md Rule 2 (line 11):

Snapshot Testing - Changes to source generator output or public APIs require running snapshot tests. Commit .verified.txt files.

What's needed:

Following the established pattern (see HttpStatusCodeAssertionGeneratorTests.cs), you should:

1. Create TUnit.Assertions.SourceGenerator.Tests/HttpResponseMessageAssertionGeneratorTests.cs
2. Run snapshot tests: dotnet test TUnit.Assertions.SourceGenerator.Tests
3. Commit the resulting .verified.txt files (4 files, one per target framework)

Why this matters: The [GenerateAssertion] attribute triggers source code generation. Snapshot tests ensure the generated code is correct and track changes over time. Without them, we can't verify the source generator produces the expected assertion wrapper classes.

Example test file structure:

public class HttpResponseMessageAssertionGeneratorTests : TestsBase<AssertionDataSourceDrivenGenerator>
{
    [Test]
    public Task HttpResponseMessage_Assertions() => RunTest(Path.Combine(Git.RootDirectory.FullName,
        "TUnit.Assertions",
        "Conditions",
        "HttpResponseMessageAssertionExtensions.cs"));
}

---

After fixing: This will be ready to merge! The feature itself is well-designed and the HTTP assertions will be a great addition to TUnit.