-
-
Notifications
You must be signed in to change notification settings - Fork 108
fix: Duplicated output in "Detailed" mode #4257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
SummaryFixes duplicated output in detailed mode by conditionally adding StandardOutputProperty/StandardErrorProperty only when NOT in detailed output mode. Critical IssuesNone found ✅ Suggestions1. Update
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This pull request fixes issue #4256 where test output was duplicated when running in "Detailed" output mode. The root cause was that in detailed mode, the Microsoft.Testing.Platform already displays output in real-time, and TUnit was also adding it to the test node properties, resulting in duplicate display.
Key Changes
- Added a public
IsDetailedOutputproperty toVerbosityServiceto expose the detailed output mode flag - Modified test node creation logic to conditionally skip adding
StandardOutputPropertyandStandardErrorPropertywhen in detailed mode - Implemented a caching mechanism for the detailed output check to avoid repeated service lookups
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
TUnit.Engine/Services/VerbosityService.cs |
Exposed the internal _isDetailedOutput field via a new public property IsDetailedOutput to make it accessible to other components |
TUnit.Engine/Extensions/TestExtensions.cs |
Added logic to check if detailed output mode is enabled and conditionally skip adding output properties to test nodes to prevent duplication; implemented caching for the detailed output check |
| private static bool IsDetailedOutput(TestContext testContext) | ||
| { | ||
| if (_cachedIsDetailedOutput.HasValue) | ||
| { | ||
| return _cachedIsDetailedOutput.Value; | ||
| } | ||
|
|
||
| if (testContext.Services.GetService<VerbosityService>() is not {} verbosityService) | ||
| { | ||
| _cachedIsDetailedOutput = false; | ||
| return false; | ||
| } | ||
|
|
||
| _cachedIsDetailedOutput = verbosityService.IsDetailedOutput; | ||
| return _cachedIsDetailedOutput.Value; | ||
| } |
Copilot
AI
Jan 7, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The static field _cachedIsDetailedOutput is accessed and modified from multiple threads without synchronization, which could lead to a race condition. While the race is benign in this case (both threads would cache the same value), it violates thread-safety best practices and could theoretically result in the check being performed multiple times.
Consider using Volatile.Read and Volatile.Write, or initializing this value once during service provider initialization rather than lazy caching, similar to how the value is stored in VerbosityService itself. The IsTrxEnabled method has the same issue.
Fixes #4256