feat: TUnit.AspNetCore

[thomhurst]

ASP.NET helpers for TUnit

WebApplicationTest - Base class for ASP.NET tests, which helps created isolated test servers for each test.
TUnitLogger - Correlates server logs back to a TUnit test's context
HttpExchangeCapture - Registers a middleware that captures requests and responses so your tests can inspect and assert on them

[claude]

PR Review: TUnit.AspNetCore

Excellent work! This is a well-designed addition to TUnit with strong architecture and API design. I found one critical issue and several minor improvements:

Critical Issue

ClassDataSourceConstructorAnalyzer.cs:113-145 - The HasAccessibleParameterlessConstructor method doesn't detect implicitly-defined parameterless constructors. Classes without explicit constructors have an implicit public parameterless constructor, but the current code only checks explicit constructors in InstanceConstructors and returns false.

Fix: Add logic to return true when constructors.Length == 0 or all constructors have parameters, unless the type is abstract or static.

Moderate Issue

HttpExchangeCaptureMiddleware.cs:32-57 - Potential stream leak if _next(context) throws before line 56. The responseBodyStream is never copied back to originalBodyStream on exception. Need to ensure stream restoration in finally block even on exception.

Minor Issues

1. ReadBodyAsync (line 121-142) - Should use ArrayPool instead of fixed buffer allocation (hot path optimization)
2. WebApplicationTest.cs:89 - Error message should include GetType().Name for diagnostics
3. Missing security warning - HttpExchangeCapture XML docs should warn against production use
4. Test coverage gaps - Missing tests for implicit constructors, middleware exceptions, concurrent access

Strengths

• Delegating factory pattern is elegant and correct
• Depth-first nested object initialization in StaticPropertyHandler ensures proper initialization order
• Clean separation between async setup and sync configuration
• Excellent helper methods (GetIsolatedName, ReplaceService)
• Comprehensive documentation with examples
• Follows TUnit principles (modern C#, AOT-compatible, performance-conscious)

Verdict

Approve with changes. Fix the critical analyzer bug before merge. Great work overall - the architecture is solid!

[claude]

Pull Request Review: TUnit.AspNetCore

Summary

This PR introduces TUnit.AspNetCore, a comprehensive ASP.NET Core testing library, along with important improvements to the analyzer infrastructure and core framework. The implementation is well-designed and follows TUnit's architectural principles.

---

✅ Strengths

1. Excellent Architecture & Design

• Delegating Factory Pattern: The WebApplicationTest<TFactory, TEntryPoint> base class uses a smart pattern with a global factory and per-test delegating factories, enabling true test isolation while supporting parallel execution.
• Async Setup Lifecycle: The SetupAsync() → ConfigureTestConfiguration() → ConfigureTestServices() flow elegantly solves the "async initialization before sync configuration" problem common in ASP.NET Core testing.
• Test Isolation Helpers: GetIsolatedName() and GetIsolatedPrefix() provide clean abstractions for generating unique resource names per test.

2. HTTP Exchange Capture

The middleware-based HTTP capture system is well-implemented:

• Configurable body capture with size limits
• Efficient buffering strategy using MemoryStream
• Clean assertion API with HttpCapture.Last, HttpCapture.All, etc.
• Thread-safe capture storage with proper locking

3. Strong Analyzer Foundation

The new ClassDataSourceConstructorAnalyzer (TUnit0061):

• Correctly validates parameterless constructor availability at compile time
• Handles edge cases: structs, abstract classes, type parameters, accessibility levels
• Comprehensive test coverage (410 lines of tests)
• Proper error messages guiding users to solutions

4. Code Quality

• Modern C# patterns: collection expressions, file-scoped namespaces, nullable annotations
• Proper AOT annotations ([DynamicallyAccessedMembers])
• Clear XML documentation with examples
• Extension methods follow TUnit conventions

---

🔍 Issues & Recommendations

Critical Issues ⚠️

1. Missing Dual-Mode Implementation Verification

Location: Core changes to ClassDataSourceAttribute and property injection
Issue: Per CLAUDE.md Rule 1, ALL changes must work identically in both source-generated and reflection modes. The PR modifies:

• TUnit.Core/Attributes/TestData/ClassDataSourceAttribute.cs (lines 82-116)
• TUnit.Engine/Services/StaticPropertyHandler.cs (lines 45-74)
• TUnit.Core.SourceGenerator/CodeGenerators/StaticPropertyInitializationGenerator.cs (lines 16-42)

Question: Have you verified that the nested property injection logic works identically in both modes? I don't see explicit dual-mode tests for this scenario.

Recommendation: Add test cases like:

[Test]
[Arguments(ExecutionMode.SourceGenerated)]
[Arguments(ExecutionMode.Reflection)]
public async Task NestedPropertyInjection_WorksInBothModes(ExecutionMode mode) { }

---

2. Performance Concern: ArrayPool Not Used

Location: TUnit.AspNetCore/Interception/HttpExchangeCaptureMiddleware.cs:124

var buffer = new byte[Math.Min(maxSize, 81920)]; // 80KB chunks

Issue: This is a hot path executed on every HTTP request. Allocating an 80KB byte array per request creates pressure on the GC, especially for high-throughput tests.

Recommendation: Use ArrayPool<byte>.Shared (per CLAUDE.md Rule 4):

var bufferSize = Math.Min(maxSize, 81920);
var buffer = ArrayPool<byte>.Shared.Rent(bufferSize);
try {
    // ... existing logic ...
} finally {
    ArrayPool<byte>.Shared.Return(buffer);
}

---

Major Issues 🟡

3. Potential Memory Leak in HttpExchangeCapture

Location: TUnit.AspNetCore/Interception/HttpExchangeCapture.cs
Issue: The _exchanges list grows unbounded. For long-running tests with many requests, this could consume significant memory.

Recommendation: Add a configurable limit or auto-cleanup:

public int MaxCapturedExchanges { get; set; } = 1000;

public void Add(CapturedHttpExchange exchange)
{
    lock (_lock)
    {
        _exchanges.Add(exchange);
        if (_exchanges.Count > MaxCapturedExchanges)
        {
            _exchanges.RemoveAt(0); // FIFO removal
        }
    }
}

---

4. Analyzer May Produce False Negatives

Location: TUnit.Analyzers/ClassDataSourceConstructorAnalyzer.cs:124-148
Issue: The analyzer only checks for public, internal, and protected internal constructors. However, for classes in the same assembly, a protected constructor in a base class might be accessible if the test class derives from it.

Current Logic:

if (constructor.DeclaredAccessibility == Accessibility.Public ||
    constructor.DeclaredAccessibility == Accessibility.Internal ||
    constructor.DeclaredAccessibility == Accessibility.ProtectedOrInternal)

Edge Case:

public abstract class DataSourceBase { protected DataSourceBase() { } }
public class MyDataSource : DataSourceBase { } // No constructor = compiler error if analyzer is too strict

[ClassDataSource<MyDataSource>] // Should be valid if test class derives from DataSourceBase

Recommendation: This is likely acceptable as-is (protected constructors are rare in data sources), but consider documenting this limitation or adding a code fix suggesting IAsyncInitializer for complex initialization.

---

5. Missing Cancellation Token Propagation

Location: TUnit.AspNetCore/Logging/TUnitLogger.cs
Issue: The logger doesn't accept a CancellationToken, which could cause delays during test cleanup if logging is slow.

Recommendation: While not critical, consider adding CancellationToken support to async log operations per CLAUDE.md guidelines.

---

Minor Issues 🟢

6. Inconsistent Null Handling

Location: WebApplicationTest.cs:89

public WebApplicationFactory<TEntryPoint> Factory => _factory ?? throw new InvalidOperationException(
        "Factory is not initialized...");

Issue: The exception message is detailed, but the property doesn't use the modern required keyword pattern used elsewhere in TUnit.

Recommendation: Consider using required or add a [MemberNotNull] attribute for clarity.

---

7. StringBuilder Pool Not Used

Location: HttpExchangeCaptureMiddleware.cs:125

var builder = new StringBuilder();

Issue: While not as critical as the byte buffer, StringBuilder is allocated per request.

Recommendation: Use object pooling if performance testing shows significant allocation pressure.

---

8. Public API Changes Not Fully Verified

Location: TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.*.verified.txt
Issue: The snapshot files show changes to ClassDataSourceAttribute and MethodDataSourceAttribute, indicating API surface changes.

Recommendation: Ensure these are intentional and backward-compatible. The changes appear to be adding optional parameters (Keys property), which should be fine.

---

🧪 Test Coverage Analysis

Excellent Coverage:

✅ ClassDataSourceConstructorAnalyzer: 10 comprehensive test cases covering all edge cases
✅ Example Integration Tests: 17 test files demonstrating real-world usage (Todo API, Redis, Kafka, parallel isolation)
✅ HTTP Capture Examples: TodoApiTests.cs shows proper usage patterns

Missing/Unclear:

❓ Dual-Mode Tests: No explicit tests verifying source-gen vs reflection parity for new features
❓ Performance Tests: No benchmarks for HTTP capture middleware overhead
❓ Concurrency Tests: No stress tests for HttpExchangeCapture thread safety under high parallelism

---

🎯 Compliance with CLAUDE.md

Rule	Status	Notes
Rule 1: Dual-Mode	⚠️ Unclear	Need explicit verification for property injection changes
Rule 2: Snapshots	✅ Pass	Public API snapshots updated correctly
Rule 3: No VSTest	✅ Pass	Uses Microsoft.Testing.Platform
Rule 4: Performance	⚠️ Partial	Missing ArrayPool usage in hot path
Rule 5: AOT/Trimming	✅ Pass	Proper [DynamicallyAccessedMembers] annotations
Code Style	✅ Pass	Modern C# 12 syntax, collection expressions, file-scoped namespaces

---

📋 Pre-Commit Checklist Status

• ✅ All tests pass (assumed - CI will verify)
• ✅ Source generator changes: snapshots accepted
• ✅ Public API changes: snapshots accepted
• ⚠️ Dual-mode feature: Verification needed
• ❓ Performance-critical: Profiling needed (HTTP middleware is hot path)
• ✅ Touching reflection: AOT annotations present
• ✅ Code follows style guide
• ✅ No breaking changes

---

🎉 Final Verdict

This is high-quality work that adds significant value to TUnit. The ASP.NET Core integration is well-architected, the analyzer improves DX, and the examples demonstrate real-world patterns.

Recommendation: Approve with minor changes

Required Changes:

1. ✅ Add ArrayPool<byte> to HttpExchangeCaptureMiddleware.ReadBodyAsync (performance critical)
2. ✅ Verify dual-mode parity for nested property injection (add test or confirm existing coverage)

Suggested Improvements:

3. Add MaxCapturedExchanges limit to prevent memory leaks
4. Document analyzer limitations for protected constructors
5. Consider adding performance benchmarks for HTTP capture overhead

---

💡 Kudos

Special recognition for:

• Clean separation of concerns: Logging, service replacement, HTTP capture are independent
• Developer experience: Extension methods like ReplaceService<T> make tests readable
• Documentation: XML comments with examples throughout
• Test examples: The Todo/Redis/Kafka examples serve as excellent documentation

Great work! 🚀

[Copilot]

Pull request overview

This PR introduces TUnit.AspNetCore, a new library that provides ASP.NET Core integration testing helpers for TUnit. The implementation includes base classes for isolated per-test web application factories, correlated logging, and HTTP request/response capture middleware.

Key Changes

• New TUnit.AspNetCore library with WebApplicationTest<TFactory, TEntryPoint> base class enabling per-test server isolation via delegating factories
• Logging integration (TUnitLogger, TUnitLoggerProvider) to correlate ASP.NET logs back to test context
• HTTP capture middleware to intercept and inspect requests/responses for test assertions
• Core framework enhancements to support open generic types in source generation and improved property injection with nested object initialization

Reviewed changes

Copilot reviewed 62 out of 62 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
TUnit.AspNetCore/WebApplicationTest.cs	Core base class providing per-test factory isolation with lifecycle hooks
TUnit.AspNetCore/TestWebApplicationFactory.cs	Factory wrapper enabling delegated configuration per test
TUnit.AspNetCore/Logging/*.cs	Logging provider and logger to capture ASP.NET logs in test output
TUnit.AspNetCore/Interception/*.cs	HTTP exchange capture middleware and storage for request/response inspection
TUnit.AspNetCore/Extensions/*.cs	Extension methods for service replacement and logging configuration
TUnit.Core/Attributes/TestData/ClassDataSourceAttribute.cs	Refactored to support parameterless constructor with type inference
TUnit.Engine/Services/StaticPropertyHandler.cs	Enhanced to initialize nested objects depth-first before parents
TUnit.Core.SourceGenerator/*.cs	Improved handling of open generic types and array constant formatting
TUnit.Analyzers/ClassDataSourceConstructorAnalyzer.cs	New analyzer ensuring ClassDataSource types have accessible constructors
TUnit.Example.Asp.Net.TestProject/*.cs	Comprehensive example tests demonstrating isolation patterns
TUnit.Example.Asp.Net/*.cs	Example ASP.NET app with PostgreSQL, Redis, and Kafka dependencies

[Copilot]

The comment on line 123 states "Use ArrayPool for better performance with large bodies", but the code doesn't actually use ArrayPool. It allocates a byte array directly with new byte[].

To actually use ArrayPool as the comment suggests, the code should be:

var buffer = ArrayPool<byte>.Shared.Rent(Math.Min(maxSize, 81920));
try
{
    // ... existing code ...
}
finally
{
    ArrayPool<byte>.Shared.Return(buffer);
}

Either update the code to use ArrayPool (following TUnit's performance guidelines), or remove the misleading comment.

[Copilot]

Empty lines at 21-22 serve no purpose and should be removed to follow clean code practices.

Suggested change

[Copilot]

The _categoryName field is stored but never used in the Log method. Category names are typically included in log output for context. Consider either using it in the log format (e.g., Console.WriteLine($"[{logLevel}] {_categoryName}: {message}");) or removing the field if it's intentionally unused.

[Copilot]

The exception parameter is retrieved from the formatter but not included in the log output. When exceptions are logged, they should be displayed. Consider appending exception details to the message when exception is not null, for example:

var message = formatter(state, exception);
if (exception != null)
{
    message = $"{message}\n{exception}";
}

Suggested change

	if (exception is not null)
	{
	message = $"{message}{Environment.NewLine}{exception}";
	}

[Copilot]

In the comment on line 15, the description references checking if a property "must use required keyword", but the severity has been downgraded from Error to Info. The comment should be updated to accurately describe this is now a suggestion rather than a requirement, or the rule description should be updated to match the new severity level.

Suggested change

	CreateDescriptor("TUnit0043", UsageCategory, DiagnosticSeverity.Info);
	CreateDescriptor("TUnit0043", UsageCategory, DiagnosticSeverity.Error);

[Copilot]

The field _types is initialized in the parameterless constructor but can also be set in the params constructor. This means _types could be assigned twice if someone uses the parameterless constructor path. Additionally, in the GenerateDataSources method at line 86, there's a check for _types.Length == 0, but this will never be true if the params constructor was used (it would be empty array [], not null). The logic appears to work, but the dual initialization is confusing.

Consider making _types readonly and initializing it only once, or making the intent clearer with comments explaining why both constructors set it.

[Copilot]

This foreach loop implicitly filters its target sequence - consider filtering the sequence explicitly using '.Where(...)'.

[Copilot]

Write to static field from instance method, property, or constructor.

[Copilot]

These 'if' statements can be combined.

Suggested change

	// Check for an explicit parameterless constructor
	foreach (var constructor in type.InstanceConstructors)
	{
	if (constructor.Parameters.Length == 0)
	{
	// Check if the constructor is accessible
	if (constructor.DeclaredAccessibility == Accessibility.Public ||
	constructor.DeclaredAccessibility == Accessibility.Internal ||
	constructor.DeclaredAccessibility == Accessibility.ProtectedOrInternal)
	{
	return true;
	}
	// Check for an explicit accessible parameterless constructor
	foreach (var constructor in type.InstanceConstructors)
	{
	if (constructor.Parameters.Length == 0 &&
	(constructor.DeclaredAccessibility == Accessibility.Public ||
	constructor.DeclaredAccessibility == Accessibility.Internal ||
	constructor.DeclaredAccessibility == Accessibility.ProtectedOrInternal))
	{
	return true;

[Copilot]

Both branches of this 'if' statement return - consider using '?' to express intent better.

Suggested change

	if (property.IsStatic)
	{
	// Can't access static members on an unbound generic type like WebApplicationTest<,>
	// Use reflection to get the value at runtime
	return $"_ => typeof({namedTypeSymbol.GloballyQualified()}).GetProperty(\"{property.Name}\")?.GetValue(null)";
	}
	else
	{
	// Use dynamic to avoid invalid cast to open generic type
	return $"o => ((dynamic)o).{property.Name}";
	}
	return property.IsStatic
	// Can't access static members on an unbound generic type like WebApplicationTest<,>
	// Use reflection to get the value at runtime
	? $"_ => typeof({namedTypeSymbol.GloballyQualified()}).GetProperty(\"{property.Name}\")?.GetValue(null)"
	// Use dynamic to avoid invalid cast to open generic type
	: $"o => ((dynamic)o).{property.Name}";

[claude]

Pull Request Review: TUnit.AspNetCore

This PR introduces a well-designed ASP.NET Core testing helper library for TUnit. Overall, this is excellent work with strong architecture, comprehensive tests, and good documentation.

Overall Assessment: 9/10

This is high-quality work that follows TUnit conventions well and provides valuable functionality. The architecture is sound, the code is clean, and the examples are helpful.

---

✅ Strengths

Architecture & Design

• Excellent delegating factory pattern using WithWebHostBuilder for per-test isolation
• Smart async setup pattern that handles ASP.NET Core sync configuration constraints
• Well-designed isolation helpers: GetIsolatedName() and GetIsolatedPrefix()
• Good separation of concerns: logging, HTTP capture, service configuration

Code Quality

• Modern C# usage: collection expressions, file-scoped namespaces, required properties
• Performance conscious: ArrayPool usage in middleware
• Thread-safe: ConcurrentQueue in HttpExchangeCapture
• Proper resource management with using statements and async disposal

Testing

• 410 lines of comprehensive analyzer tests
• Real-world integration tests demonstrating usage patterns
• Snapshot tests properly updated

See next comment for detailed issues and recommendations...

[claude]

Critical and Major Issues

CRITICAL: TestContext.Current Mutation (TUnitAspNetLogger.cs:43)

The logger mutates global static TestContext.Current which creates race conditions in parallel tests. Multiple threads will overwrite each others context causing logs to be attributed to wrong tests.

Recommendation: Use AsyncLocal if available or document threading implications. The logger already has _context injected so this mutation may not be necessary.

---

MAJOR: Dual-Mode Implementation Verification Needed

Per CLAUDE.md Rule 1, ALL changes must work identically in both source-generated and reflection modes.

Action Required: Verify the new Shared parameter on ClassDataSourceAttribute works identically in TUnit.Core.SourceGenerator and TUnit.Engine.

---

MAJOR: Potential SQL Injection (TodoTestBase.cs:74-82)

While tableName is controlled, using string interpolation for SQL CREATE TABLE commands is risky. Add validation to ensure table names are safe, especially since this is example code that may be copied.

---

MAJOR: Middleware Stream Restoration (HttpExchangeCaptureMiddleware.cs:40-51)

The stream restoration in finally block could fail in extreme edge cases. Consider documenting this is acceptable for test middleware or restructure for guaranteed restoration.

[claude]

Minor Issues and Suggestions

Field Keyword Usage (WebApplicationTest.cs:244)

Uses C# 13 field keyword for auto-property backing field. Ensure all target frameworks and TUnit users support C# 13.

Missing CancellationToken Support

Several async methods lack CancellationToken parameters:

• HttpExchangeCaptureMiddleware.ReadBodyAsync (line 127)
• TodoTestBase.CreateTableAsync (line 68)
• TodoTestBase.SeedTodosAsync (line 101)

While not critical for tests, best practice would add them.

Magic Number in Buffer Size

Extract 81920 to named constant like DefaultBufferSize = 80 * 1024 at HttpExchangeCaptureMiddleware.cs:129

Performance Suggestions

• Consider object pooling for StringBuilder in middleware (currently allocates per request)
• HttpExchangeCapture.Exchanges creates new array on each access (line 35) - consider caching if accessed frequently

Security Concerns

Header capture could expose sensitive data (Authorization headers, cookies). Consider adding filtering options for sensitive headers.

Test Coverage Gaps

• Add tests for HttpExchangeCapture query methods
• Add tests for TUnitLogger with parallel execution scenarios
• Add test for HttpCapture with EnableHttpExchangeCapture = false

[claude]

Recommendations Summary

Must Fix Before Merge

1. Review TestContext.Current mutation for thread safety
2. Verify dual-mode implementation works identically (source-gen vs reflection)
3. Add SQL table name validation to prevent injection

Should Fix Before or Soon After Merge

4. Add filtering for sensitive headers in HttpExchangeCapture
5. Add CancellationToken support to public async APIs
6. Extract magic numbers to named constants
7. Add tests for parallel execution scenarios with logging

Nice to Have

8. Document migration patterns from other frameworks (xUnit/NUnit)
9. Consider object pooling for frequently allocated objects
10. Add performance benchmarks for middleware overhead
11. Document TestContext.Current behavior and threading implications
12. Add migration guide for users coming from other test frameworks

---

Code Style Compliance (CLAUDE.md)

✅ Follows Guidelines:

• Modern C# syntax (collection expressions, file-scoped namespaces)
• No blocking on async (no .Result calls)
• Good use of required keyword
• Async methods have Async suffix
• Excellent XML documentation

Minor deviations:

• Some methods could use ValueTask for potentially-sync operations

---

Overall, this is excellent work! The main concerns are thread safety in logging and ensuring dual-mode parity. With those addressed, this will be a great addition to TUnit. 🎉

[claude]

Code Review: TUnit.AspNetCore

Great work on this new ASP.NET Core integration library! This is a valuable addition that will significantly improve the testing experience for ASP.NET Core applications.

✅ Strengths

1. Excellent Architecture

• Delegating Factory Pattern: The use of WithWebHostBuilder for per-test isolation is the correct approach for parallel test execution
• Clear Separation of Concerns: WebApplicationTest base class, logging, HTTP capture, and service extensions are well-separated
• Comprehensive Examples: The example tests demonstrate real-world scenarios

2. Well-Designed API

• GetIsolatedName() Helper: Brilliant utility for generating unique resource names per test
• Async Setup Pattern: SetupAsync() → ConfigureTestServices() → ConfigureTestConfiguration() flow is intuitive
• HTTP Exchange Capture: Well-designed with configurable body capture and size limits

3. Performance Conscious

• ArrayPool Usage: HttpExchangeCaptureMiddleware.cs:130 properly uses ArrayPool for reading request/response bodies
• Concurrent Collections: HttpExchangeCapture uses ConcurrentQueue for thread-safe access
• Lazy Initialization: Property injection uses Lazy to defer expensive operations

4. Good Code Quality

• Modern C# Syntax: Collection expressions, file-scoped namespaces, pattern matching all used correctly
• Proper Documentation: XML comments with examples throughout
• Error Handling: Factory property throws helpful exception if accessed before initialization

[claude]

🚨 Critical Issues

1. Missing Unit Tests for TUnit.AspNetCore Library ⚠️ BLOCKER

The new TUnit.AspNetCore library has no dedicated test project. While there are example integration tests in TUnit.Example.Asp.Net.TestProject, the library itself lacks unit tests.

Core functionality not directly tested:

• WebApplicationTest lifecycle hooks
• HttpExchangeCaptureMiddleware edge cases (large bodies, truncation, errors during request processing)
• TUnitAspNetLogger scope management
• ServiceCollectionExtensions helper methods

Recommendation: Create TUnit.AspNetCore.Tests project with tests for middleware behavior, logger integration, factory isolation, and service replacement helpers.

2. Potential Resource Leak in HttpExchangeCaptureMiddleware ⚠️

Location: TUnit.AspNetCore/Interception/HttpExchangeCaptureMiddleware.cs:40-51

If an exception occurs between setting context.Response.Body (line 37) and the try block, the finally won't execute, leaving the response body stream in an incorrect state.

Recommendation: Move the stream assignment inside the try block to ensure the finally block always executes and restores the original stream.

3. ClassDataSourceConstructorAnalyzer: Missing Edge Case

Location: TUnit.Analyzers/ClassDataSourceConstructorAnalyzer.cs:133-138

The analyzer doesn't detect when a class has required properties with init-only setters, which would prevent parameterless construction at runtime.

Recommendation: Check for required properties when allowing implicit constructors.

4. Dual-Mode Implementation Compliance ✅ VERIFIED

Excellent: The changes correctly maintain dual-mode support in both source-gen and reflection paths.

[claude]

⚠️ High Priority Issues

5. TUnitAspNetLogger: TestContext.Current Thread Safety 🧵

Location: TUnit.AspNetCore/Logging/TUnitAspNetLogger.cs:43

Setting TestContext.Current = _context in a logger called from ASP.NET middleware threads could cause race conditions in parallel tests if TestContext.Current is a static field.

Recommendation: Verify that TestContext.Current is thread-local (AsyncLocal) and document threading expectations.

6. HttpExchangeCapture: Potential Memory Growth

Location: TUnit.AspNetCore/Interception/HttpExchangeCapture.cs:56

ConcurrentQueue has no built-in size limit. Long-running tests with many requests could accumulate unbounded memory.

Recommendation: Add optional max size with eviction of oldest entries when limit is exceeded.

7. Property Initialization Order Confusion

Location: TUnit.AspNetCore/WebApplicationTest.cs:78-79

Using the non-generic ClassDataSourceAttribute instead of ClassDataSource could be confusing.

Recommendation: Use explicit generic form ClassDataSource for consistency.