Test web application factory migration #36
Conversation
…pdated one binding fixture usage
…6-TestWebApplicationFactoryChanges
…pdated one binding fixture usage
…RenderTypes Fixtures
This reverts commit 5f953d9.
There was a problem hiding this comment.
Pull Request Overview
This pull request migrates integration tests from using the deprecated TestServer/TestServerBuilder pattern to the modern WebApplicationFactory pattern. This change enhances test isolation and maintainability while ensuring compatibility with the latest ASP.NET Core testing practices.
- Replace TestServer/TestServerBuilder with WebApplicationFactory pattern across all integration tests
- Introduce a new TestWebApplicationProgram class to serve as the entry point for test applications
- Remove the obsolete TestPagesProgram and consolidate all test configurations to use the unified approach
Reviewed Changes
Copilot reviewed 47 out of 47 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| TestWebApplicationProgram.cs | New entry point class for test applications using WebApplicationFactory |
| Tracking fixtures | Updated to use WebApplicationFactory with proper service configuration |
| TagHelper fixtures | Migrated from TestServer to WebApplicationFactory pattern |
| Pages fixtures | Consolidated to use TestWebApplicationProgram instead of TestPagesProgram |
| Error handling fixtures | Refactored to build isolated service providers for independent testing |
| Benchmarks | Updated to use WebApplicationFactory for performance testing |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| httpMessage.Headers.Add("Cookie", aspnet!.ToString()); | ||
| } | ||
|
|
||
| httpMessage.RequestUri = layoutRequest.BuildDefaultSitecoreLayoutRequestUri(httpMessage.RequestUri!, new[] { "param1", "param2" }); |
There was a problem hiding this comment.
[nitpick] Replace array initialization syntax new[] { "param1", "param2" } with the more explicit new string[] { "param1", "param2" } for better readability and consistency with the codebase.
| httpMessage.RequestUri = layoutRequest.BuildDefaultSitecoreLayoutRequestUri(httpMessage.RequestUri!, new[] { "param1", "param2" }); | |
| httpMessage.RequestUri = layoutRequest.BuildDefaultSitecoreLayoutRequestUri(httpMessage.RequestUri!, new string[] { "param1", "param2" }); |
| ISitecoreLayoutClient layoutClient = _factory.Services.GetRequiredService<ISitecoreLayoutClient>(); | ||
|
|
||
| SitecoreLayoutRequest request = []; | ||
| SitecoreLayoutRequest request = new SitecoreLayoutRequest(); |
There was a problem hiding this comment.
[nitpick] Consider using collection initializer syntax new() instead of new SitecoreLayoutRequest() for consistency with the target-typed new expressions used elsewhere in the codebase.
| SitecoreLayoutRequest request = new SitecoreLayoutRequest(); | |
| SitecoreLayoutRequest request = new(); |
| ISitecoreLayoutClient layoutClient = _factory.Services.GetRequiredService<ISitecoreLayoutClient>(); | ||
|
|
||
| SitecoreLayoutRequest request = []; | ||
| SitecoreLayoutRequest request = new SitecoreLayoutRequest(); |
There was a problem hiding this comment.
[nitpick] Consider using collection initializer syntax new() instead of new SitecoreLayoutRequest() for consistency with the target-typed new expressions used elsewhere in the codebase.
| SitecoreLayoutRequest request = new SitecoreLayoutRequest(); | |
| SitecoreLayoutRequest request = new(); |
| app.UseRequestLocalization(options => | ||
| { | ||
| List<CultureInfo> supportedCultures = [new("en"), new("ru-RU")]; | ||
| List<CultureInfo> supportedCultures = new() { new("en"), new("ru-RU") }; |
There was a problem hiding this comment.
[nitpick] Consider using collection expression syntax [new("en"), new("ru-RU")] for better readability and consistency with modern C# patterns where available.
| List<CultureInfo> supportedCultures = new() { new("en"), new("ru-RU") }; | |
| List<CultureInfo> supportedCultures = [ new("en"), new("ru-RU") ]; |
…ting up the response in the constructor consistently in EdgeSitemapProxyFixture
Migrate integration test fixtures to shared TestWebApplicationFactory
…ISitecoreLayoutClient singleton instead of constructing a sampleRequest/sampleResponse.- ExperienceEditorCustomRoutingFixture.cs
- Use the same approach TestServerBuilder used: register a simple mock ISitecoreLayoutClient singleton instead of constructing a sampleRequest/sampleResponse.- ExperienceEditorCustomRoutingFixture.cs - wire layout service to mock HttpClient in RenderingEngine benchmarks
- use app.Start() in TestWebApplicationProgram - Add comment explaining variable startedServer - Use the same layout-service builder pattern previously used in TrackingBenchmarks
…n EdgeSitemapProxyFixture
…ctor pattern like other fixtures
- use _ = _factory.Server; to clearly indicate the variable is intentionally - using the more modern collection expression syntax for consistency in EdgeSitemapProxyFixture - Refactor RequestHeadersValidationFixture to implement similar constructor pattern like other fixtures
Description / Motivation
Testing
Terms