V9.0.0/host consistency and httpcontext improvement #15
Conversation
…ateOnBuild and ValidateScopes) and have a running host
…for both HostTest and AspNetCoreHostTest
|
Caution Review failedThe pull request is closed. WalkthroughThe pull request introduces several modifications across multiple classes in the Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (7)
test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Assets/ScopedCorrelation.cs (1)
5-7: Consider adding XML documentation.To improve code clarity and maintainability, consider adding XML documentation to the
ScopedCorrelationrecord. This would help other developers understand its purpose and usage within the test suite.Here's a suggested implementation:
+ /// <summary> + /// Represents a scoped correlation token for testing purposes. + /// </summary> public sealed record ScopedCorrelation : CorrelationToken { }test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Assets/SingletonCorrelation.cs (1)
1-8: LGTM! Consider adding documentation for clarity.The implementation of
SingletonCorrelationas a sealed record inheriting fromCorrelationTokenis a good choice for an immutable correlation token type. This aligns well with the PR objectives of improving service handling and HTTP context.Consider adding XML documentation to clarify the intended usage of this correlation token, especially its singleton nature. For example:
/// <summary> /// Represents a correlation token intended for singleton usage within the application. /// </summary> /// <remarks> /// This token type is useful for scenarios where a single, application-wide correlation identifier is needed. /// </remarks> public sealed record SingletonCorrelation : CorrelationToken { }This documentation would help other developers understand the purpose and proper usage of this token type.
test/Codebelt.Extensions.Xunit.Hosting.Tests/Codebelt.Extensions.Xunit.Hosting.Tests.csproj (1)
Line range hint
8-10: LGTM. Consider removing the redundant None Remove item.The inclusion of appsettings.json as content with CopyToOutputDirectory set to Always is appropriate for configuration files in test projects. This ensures that the configuration file is available during test execution.
However, the None Remove item for appsettings.json (lines 8-10) appears to be redundant with the new Content Include. Consider removing it to clean up the project file:
- <ItemGroup> - <None Remove="appsettings.json" /> - </ItemGroup>Also applies to: 12-14
src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/ServiceCollectionExtensions.cs (1)
42-42: Improved dependency injection inFakeHttpContextAccessorFactory.The update to use dependency injection for retrieving
IServiceScopeFactoryis a good improvement. It allows for better control over service lifetimes withinFakeHttpContextAccessor.However, consider wrapping the
GetRequiredServicecall in a try-catch block to provide a more informative error message ifIServiceScopeFactoryis not registered.Here's a suggested improvement:
- return new FakeHttpContextAccessor(provider.GetRequiredService<IServiceScopeFactory>()); + try + { + return new FakeHttpContextAccessor(provider.GetRequiredService<IServiceScopeFactory>()); + } + catch (InvalidOperationException ex) + { + throw new InvalidOperationException("Failed to create FakeHttpContextAccessor. Ensure IServiceScopeFactory is registered in the service collection.", ex); + }src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/AspNetCoreHostFixture.cs (1)
Line range hint
1-124: Overall assessment: Positive enhancement with minor considerationsThe addition of the conditional compilation block for .NET 9.0+ enhances the
AspNetCoreHostFixtureclass by providing stricter service validation in newer .NET versions. This change maintains backward compatibility while leveraging new features, which is a good practice in library development.To further improve the class:
- Consider extracting the host configuration logic into separate methods to improve readability and maintainability of the
ConfigureHostmethod.- Evaluate if any of the new .NET 9.0+ features could be backported or if there are equivalent implementations for earlier versions to maintain consistent behavior across .NET versions where possible.
src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/Http/FakeHttpContextAccessor.cs (1)
24-27: Consider making the greeting message configurable or more generic.The hardcoded greeting in
MakeGreeting("Hello awesome developers!")might not be suitable for all testing scenarios. It could be beneficial to make the greeting message configurable or use a more generic placeholder to prevent any unintended effects in tests.Apply this diff to make the greeting configurable:
- fc.Set<IHttpResponseBodyFeature>(new StreamResponseBodyFeature(MakeGreeting("Hello awesome developers!"))); + fc.Set<IHttpResponseBodyFeature>(new StreamResponseBodyFeature(MakeGreeting(greeting: "Test Response")));Or consider adding a parameter to the constructor to pass a custom greeting.
test/Codebelt.Extensions.Xunit.Hosting.Tests/HostTestTest.cs (1)
Line range hint
28-35: Shared state detected due to staticScopedCorrelationscollectionAdding
ScopedCorrelationinstances to a static collection can cause tests to interact with each other's data, leading to unreliable test results.After making
ScopedCorrelationsan instance field, ensure that each test operates on its own instance to maintain test isolation.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (12)
- src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/AspNetCoreHostFixture.cs (1 hunks)
- src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/Http/FakeHttpContextAccessor.cs (2 hunks)
- src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/ServiceCollectionExtensions.cs (2 hunks)
- src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/WebHostTest.cs (1 hunks)
- src/Codebelt.Extensions.Xunit.Hosting/HostFixture.cs (4 hunks)
- test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/AspNetCoreHostTestTest.cs (5 hunks)
- test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Assets/ScopedCorrelation.cs (1 hunks)
- test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Assets/SingletonCorrelation.cs (1 hunks)
- test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Assets/TransientCorrelation.cs (1 hunks)
- test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests.csproj (1 hunks)
- test/Codebelt.Extensions.Xunit.Hosting.Tests/Codebelt.Extensions.Xunit.Hosting.Tests.csproj (1 hunks)
- test/Codebelt.Extensions.Xunit.Hosting.Tests/HostTestTest.cs (4 hunks)
✅ Files skipped from review due to trivial changes (1)
- test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests.csproj
🧰 Additional context used
🔇 Additional comments (19)
test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Assets/ScopedCorrelation.cs (1)
1-8: Implementation looks good.The
ScopedCorrelationrecord is correctly defined as a sealed record inheriting fromCorrelationToken. This structure is suitable for its likely use in testing scoped correlation scenarios.test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/Assets/TransientCorrelation.cs (3)
1-1: LGTM: Appropriate namespace import.The import of
Cuemon.Messagingis correct, as it likely contains theCorrelationTokenclass thatTransientCorrelationinherits from.
3-4: LGTM: Appropriate namespace declaration.The namespace
Codebelt.Extensions.Xunit.Hosting.AspNetCore.Assetscorrectly reflects the file's location in the test assets directory and its purpose.
5-7: LGTM, but clarification needed on the record's purpose.The
TransientCorrelationrecord is correctly declared as sealed and inherits fromCorrelationToken. However, it's currently empty and doesn't add any new properties or behavior.Could you please clarify the purpose of this separate type? If it's intended to be used as a marker type for transient correlations, consider adding a comment explaining its usage.
To better understand the usage of this new type, let's search for its occurrences in the codebase:
✅ Verification successful
Approved. The
TransientCorrelationrecord is appropriately used in tests to differentiate transient correlation tokens. Although it doesn't add new properties or behavior now, it allows for clear and flexible testing of different lifetimes.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usages of TransientCorrelation rg --type csharp -A 5 "TransientCorrelation"Length of output: 2706
test/Codebelt.Extensions.Xunit.Hosting.Tests/Codebelt.Extensions.Xunit.Hosting.Tests.csproj (1)
18-18: LGTM. Verify compatibility with the updated package.The update of the Cuemon.Core package to version 9.0.0-preview.10 is a good practice to keep dependencies current. However, as this is a preview version, it's important to ensure that this update doesn't introduce any breaking changes or unexpected behavior in the tests.
Please run the following script to check for any potential issues:
src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/ServiceCollectionExtensions.cs (2)
19-21: Improved method signature with sensible default.The addition of a default value (
ServiceLifetime.Singleton) for thelifetimeparameter is a good improvement. It enhances usability by allowing callers to omit the parameter when the default behavior is desired, while maintaining backwards compatibility. The choice ofSingletonas the default lifetime is appropriate forIHttpContextAccessor, as it's typically used as a global service.
Line range hint
1-45: Overall structure and consistency maintained.The changes in this file are well-integrated and maintain consistency with the existing code style and structure. The modifications align with the PR objectives of improving host consistency and HTTP context handling. No issues with the overall file structure or consistency are apparent.
src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/WebHostTest.cs (1)
86-86: LGTM! Verify default lifetime in ServiceCollectionExtensions.The simplification of
AddFakeHttpContextAccessor()call aligns with the PR objectives of improving service handling. This change suggests that the default lifetime forAddFakeHttpContextAccessorhas been set toSingletoninServiceCollectionExtensions.cs.To ensure consistency, please verify the default lifetime setting in
ServiceCollectionExtensions.cs:✅ Verification successful
Verified: Default lifetime is Singleton. No issues found.
This confirms that
AddFakeHttpContextAccessor()now defaults toSingletonas intended.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the default lifetime for AddFakeHttpContextAccessor in ServiceCollectionExtensions.cs # Test: Search for the AddFakeHttpContextAccessor method definition # Expect: The method should have a default parameter value of ServiceLifetime.Singleton rg --type csharp -A 10 'public static IServiceCollection AddFakeHttpContextAccessor' srcLength of output: 1538
src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/AspNetCoreHostFixture.cs (1)
83-89: Approve with suggestions: Enhanced service provider configuration for .NET 9.0+The addition of
UseDefaultServiceProviderfor .NET 9.0 and above is a good improvement, enhancing service validation in the test environment. This change aligns with best practices for dependency injection in ASP.NET Core.Consider adding a comment explaining the rationale behind this change and its potential impacts. For example:
#if NET9_0_OR_GREATER // Configure stricter validation for .NET 9.0+ to catch DI issues early in the test environment hb.UseDefaultServiceProvider(o => { o.ValidateOnBuild = true; o.ValidateScopes = true; }); #endifPlease verify the following aspects:
- Cross-version testing: Ensure that tests run consistently across different .NET versions, given this conditional behavior.
- Performance impact: Validate that the additional validation doesn't significantly impact test execution time.
You can use the following script to check for any existing performance tests or benchmarks:
This will help identify if there are existing performance tests that should be updated or if new ones should be added to monitor any potential impact.
src/Codebelt.Extensions.Xunit.Hosting.AspNetCore/Http/FakeHttpContextAccessor.cs (4)
7-7: Add missing using directive forIServiceScopeFactory.The addition of
using Microsoft.Extensions.DependencyInjection;is necessary for theIServiceScopeFactoryinterface used in the constructor.
20-20: Confirm the necessity of the optionalIServiceScopeFactoryparameter.While adding
IServiceScopeFactoryenhances dependency injection capabilities, ensure that all usages ofFakeHttpContextAccessoraccommodate this change and that the default value ofnulldoes not introduce any unintended side effects.
28-29: Ensure proper reinitialization ofHttpContext.Calling
context.Uninitialize();followed bycontext.Initialize(fc);is correct for reinitializing theHttpContextwith the newFeatureCollection. Confirm that this sequence is necessary and does not have any side effects.
24-24:⚠️ Potential issueHandle potential null reference when
factoryis null.Since
factorycan benull, ensure that passing it toRequestServicesFeaturedoes not result in aNullReferenceException. Verify thatRequestServicesFeaturecan handle anullIServiceScopeFactorywithout issues.test/Codebelt.Extensions.Xunit.Hosting.AspNetCore.Tests/AspNetCoreHostTestTest.cs (3)
38-39: Logging Statements Added to Test MethodThe addition of logging within the
ShouldHaveResultOfBoolMiddlewareInBodymethod enhances test output and aids in debugging. The logger is correctly initialized and used.
65-88: Tests Correctly Verify Service LifetimesThe test
ShouldHaveAccessToCorrelationTokens_UsingScopedProvideraccurately verifies the behavior of singleton, transient, and scoped services within a scope. The assertions ensure that:
- Singleton instances are the same across requests.
- Transient instances are different across requests.
- Scoped instances are the same within the same scope.
146-148: Service Registrations forICorrelationTokenRegistering
ICorrelationTokenwith singleton, transient, and scoped lifetimes is appropriate for testing different service behaviors. This setup allows for thorough testing of service lifetimes and is correctly utilized in the tests.src/Codebelt.Extensions.Xunit.Hosting/HostFixture.cs (3)
16-17: Adding a synchronization lock object for thread safetyThe addition of the
private readonly object _lock = new();field provides a synchronization mechanism to ensure thread safety in theDisposemethod. This helps prevent race conditions when disposing resources from multiple threads.
61-65: Enabling service provider validation to catch configuration errors earlySetting
ValidateOnBuildandValidateScopestotrueenhances the application's robustness by ensuring that any issues with service registrations are caught during the host build process. This proactive validation helps detect misconfigured or missing services early in the development cycle.
200-208: Ensuring thread-safe disposal in theDisposemethodWrapping the disposal logic within a
lockstatement ensures that theDisposemethod is thread-safe. This prevents multiple threads from disposing of the object simultaneously, which could lead to inconsistent states or exceptions.
| /// Initializes a new instance of the <see cref="FakeHttpContextAccessor"/> class. | ||
| /// </summary> | ||
| public FakeHttpContextAccessor() | ||
| public FakeHttpContextAccessor(IServiceScopeFactory factory = null) |
There was a problem hiding this comment.
Update XML documentation to reflect constructor changes.
The constructor now accepts an optional IServiceScopeFactory, but the XML documentation has not been updated to describe this parameter. Please update the comments to maintain accurate documentation.
Apply this diff to update the XML documentation:
/// <summary>
-/// Initializes a new instance of the <see cref="FakeHttpContextAccessor"/> class.
+/// Initializes a new instance of the <see cref="FakeHttpContextAccessor"/> class with an optional <see cref="IServiceScopeFactory"/>.
/// </summary>
+/// <param name="factory">An optional service scope factory for resolving services.</param>
public FakeHttpContextAccessor(IServiceScopeFactory factory = null)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| public FakeHttpContextAccessor(IServiceScopeFactory factory = null) | |
| /// <summary> | |
| /// Initializes a new instance of the <see cref="FakeHttpContextAccessor"/> class with an optional <see cref="IServiceScopeFactory"/>. | |
| /// </summary> | |
| /// <param name="factory">An optional service scope factory for resolving services.</param> | |
| public FakeHttpContextAccessor(IServiceScopeFactory factory = null) |
| _scope = hostFixture.ServiceProvider.CreateScope(); | ||
| _correlationsFactory = () => _scope.ServiceProvider.GetServices<ICorrelationToken>().ToList(); |
There was a problem hiding this comment.
Reusing the same IServiceScope across tests may cause unintended shared state
Creating a single IServiceScope in the constructor and reusing it across multiple tests can lead to shared instances of scoped services, which might result in tests affecting each other.
Consider creating a new IServiceScope within each test method to ensure proper isolation. This can be achieved by initializing the scope at the beginning of each test and disposing of it at the end.
| private readonly IServiceScope _scope; | ||
| private readonly Func<IList<ICorrelationToken>> _correlationsFactory; | ||
| private static readonly ConcurrentBag<ICorrelationToken> ScopedCorrelations = new ConcurrentBag<ICorrelationToken>(); | ||
| private static readonly ConcurrentBag<ICorrelationToken> ScopedCorrelations = new(); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Avoid using static fields in test classes to prevent shared state across tests
The field ScopedCorrelations is declared as static, which can lead to shared state between tests and potentially cause flaky tests due to unintended interactions.
Consider making ScopedCorrelations an instance field:
-private static readonly ConcurrentBag<ICorrelationToken> ScopedCorrelations = new();
+private readonly ConcurrentBag<ICorrelationToken> ScopedCorrelations = new();📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| private readonly IServiceScope _scope; | |
| private readonly Func<IList<ICorrelationToken>> _correlationsFactory; | |
| private static readonly ConcurrentBag<ICorrelationToken> ScopedCorrelations = new ConcurrentBag<ICorrelationToken>(); | |
| private static readonly ConcurrentBag<ICorrelationToken> ScopedCorrelations = new(); | |
| private readonly IServiceScope _scope; | |
| private readonly Func<IList<ICorrelationToken>> _correlationsFactory; | |
| private readonly ConcurrentBag<ICorrelationToken> ScopedCorrelations = new(); |
| protected override void OnDisposeManagedResources() | ||
| { | ||
| _scope?.Dispose(); | ||
| } |
There was a problem hiding this comment.
Override OnDisposeManagedResources should call base class method
When overriding OnDisposeManagedResources, it's important to call the base class implementation to ensure that any disposal logic in the base class is executed.
Apply this diff to call the base class method:
protected override void OnDisposeManagedResources()
{
+ base.OnDisposeManagedResources();
_scope?.Dispose();
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| protected override void OnDisposeManagedResources() | |
| { | |
| _scope?.Dispose(); | |
| } | |
| protected override void OnDisposeManagedResources() | |
| { | |
| base.OnDisposeManagedResources(); | |
| _scope?.Dispose(); | |
| } |
| [Fact] | ||
| public void ShouldHaveAccessToCorrelationTokens_UsingRequestServices() // reference: https://github.com/dotnet/aspnetcore/blob/main/src/Http/Http/src/Features/RequestServicesFeature.cs | ||
| { | ||
| var context = _provider.GetRequiredService<IHttpContextAccessor>().HttpContext!; |
There was a problem hiding this comment.
Avoid Using the Null-Forgiving Operator
Using the null-forgiving operator ! can mask potential NullReferenceException issues. Instead, explicitly check for null to ensure the test fails with a meaningful message if HttpContext is not available.
Consider modifying the code:
-var context = _provider.GetRequiredService<IHttpContextAccessor>().HttpContext!;
+var httpContextAccessor = _provider.GetRequiredService<IHttpContextAccessor>();
+Assert.NotNull(httpContextAccessor.HttpContext);
+var context = httpContextAccessor.HttpContext!;This way, the test will explicitly assert that HttpContext is not null before proceeding.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| var context = _provider.GetRequiredService<IHttpContextAccessor>().HttpContext!; | |
| var httpContextAccessor = _provider.GetRequiredService<IHttpContextAccessor>(); | |
| Assert.NotNull(httpContextAccessor.HttpContext); | |
| var context = httpContextAccessor.HttpContext!; |
| #if NET9_0_OR_GREATER | ||
| [Fact] | ||
| public void ShouldThrowInvalidOperationException_BecauseOneOfTheServicesIsScoped() | ||
| { | ||
| var ex = Assert.Throws<InvalidOperationException>(() => _provider.GetServices<ICorrelationToken>()); | ||
|
|
||
| TestOutput.WriteLine(ex.Message); | ||
|
|
||
| Assert.Contains("from root provider because it requires scoped service", ex.Message); | ||
| } | ||
| #endif |
There was a problem hiding this comment.
Improve Exception Message Assertion for Robustness
When asserting on exception messages, consider that they may vary between .NET versions or due to localization. To make the test more robust, use culture-invariant checks or assert on exception properties if available.
Consider modifying the assertion as follows:
-Assert.Contains("from root provider because it requires scoped service", ex.Message);
+Assert.Contains("requires scoped service", ex.Message, StringComparison.OrdinalIgnoreCase);Alternatively, if the exception provides specific properties or error codes, assert on those to avoid dependency on message text.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #if NET9_0_OR_GREATER | |
| [Fact] | |
| public void ShouldThrowInvalidOperationException_BecauseOneOfTheServicesIsScoped() | |
| { | |
| var ex = Assert.Throws<InvalidOperationException>(() => _provider.GetServices<ICorrelationToken>()); | |
| TestOutput.WriteLine(ex.Message); | |
| Assert.Contains("from root provider because it requires scoped service", ex.Message); | |
| } | |
| #endif | |
| #if NET9_0_OR_GREATER | |
| [Fact] | |
| public void ShouldThrowInvalidOperationException_BecauseOneOfTheServicesIsScoped() | |
| { | |
| var ex = Assert.Throws<InvalidOperationException>(() => _provider.GetServices<ICorrelationToken>()); | |
| TestOutput.WriteLine(ex.Message); | |
| Assert.Contains("requires scoped service", ex.Message, StringComparison.OrdinalIgnoreCase); | |
| } | |
| #endif |
| var host = hb.Build(); | ||
| Task.Run(() => host.StartAsync().ConfigureAwait(false)) | ||
| .ConfigureAwait(false) | ||
| .GetAwaiter() | ||
| .GetResult(); | ||
| Host = host; |
There was a problem hiding this comment.
Simplify host startup to avoid unnecessary Task.Run and potential deadlocks
The current implementation wraps host.StartAsync() inside a Task.Run and then synchronously waits for it using .GetAwaiter().GetResult(). This pattern can introduce unnecessary complexity and potential deadlocks. Since StartAsync() returns a Task, you can synchronously wait on it directly.
Apply this diff to simplify the host startup:
var host = hb.Build();
-Task.Run(() => host.StartAsync().ConfigureAwait(false))
- .ConfigureAwait(false)
- .GetAwaiter()
- .GetResult();
+host.StartAsync().GetAwaiter().GetResult();
Host = host;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| var host = hb.Build(); | |
| Task.Run(() => host.StartAsync().ConfigureAwait(false)) | |
| .ConfigureAwait(false) | |
| .GetAwaiter() | |
| .GetResult(); | |
| Host = host; | |
| var host = hb.Build(); | |
| host.StartAsync().GetAwaiter().GetResult(); | |
| Host = host; |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #15 +/- ##
==========================================
- Coverage 75.20% 68.62% -6.58%
==========================================
Files 31 20 -11
Lines 621 408 -213
Branches 79 59 -20
==========================================
- Hits 467 280 -187
+ Misses 150 126 -24
+ Partials 4 2 -2 ☔ View full report in Codecov by Sentry. |
|
gimlichael
deleted the
v9.0.0/host-consistency-and-httpcontext-improvement
branch
PR Classification
Code enhancement and new feature implementation.
PR Summary
Enhanced service handling and added support for scoped services with improved test coverage.
AspNetCoreHostFixture.cs: Added conditional compilation for .NET 9.0+ and ensured asynchronous host start,FakeHttpContextAccessor: IntroducedIServiceScopeFactoryand updated initialization logic,ServiceCollectionExtensions.cs: ModifiedAddFakeHttpContextAccessorto default toSingletonlifetime,HostFixture.cs: Added thread-safety toDisposemethod,AspNetCoreHostTestTest.cs: Added new tests for scoped services and correlation tokens.Summary by CodeRabbit
New Features
FakeHttpContextAccessorwith service provider integration.ScopedCorrelation,SingletonCorrelation, andTransientCorrelation.AddFakeHttpContextAccessor.Bug Fixes
HostFixtureclass during host configuration and disposal.Tests
Chores