Rewrite AcceptanceTests to use JSON files and JsonNode.DeepEquals

[Copilot]

Rewrite AcceptanceTests to use JSON files and JsonNode.DeepEquals

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Replace inline parameter-checking assertions with JsonNode.DeepEquals against expected JSON files.

Description

The minimal_api and mixed_api acceptance tests used manual assertions (checking path keys, parameter names, version strings). This is fragile and harder to maintain than comparing against a known-good document.

All three acceptance tests now use the same pattern:

using var stream = File.OpenRead( Path.Combine( AppContext.BaseDirectory, "Content", "v1-minimal.json" ) );
var expected = await JsonNode.ParseAsync( stream, default, default, cancellationToken );
// ...
JsonNode.DeepEquals( actual, expected ).Should().BeTrue();

Changes:

• AcceptanceTest.cs — replaced inline assertions in minimal_api and mixed_api tests with JsonNode.DeepEquals file comparisons; removed unnecessary AddProblemDetails() from the minimal API test
• Added Content/v1-minimal.json — expected OpenAPI document for the pure minimal API scenario
• Added Content/v1-mixed.json — expected OpenAPI document for the controller + minimal API scenario

Note: The existing v1.json was not modified. The controller_should_generate_expected_open_api_document test has a pre-existing failure due to culture-dependent date formatting (1/1/2026 vs 01/01/2026) and line ending differences in v1.json.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[sander1095]

@copilot Please create a new issue at dotnet/aspnet-api-versioning for this culture issues.