Feature/advanced console output recorder#2
Conversation
…ting - Implement Event.AdvancedConsoleOutputRecorder with beautiful tree structure - Add SF symbols support with colors (play.circle, checkmark.circle, x.circle, etc.) - Right-aligned timing display with 80-column fixed width - Unicode box-drawing characters for hierarchical test output - Issues displayed as sub-nodes under failed tests - Enhanced start message with test count and running status - Thread-safe parallel execution support - Color-coded final summary with status icons - Replace basic ConsoleOutputRecorder with enhanced version - Add demo test files for validation Features: ✅ Hierarchical tree structure with proper indentation ✅ SF Symbols on macOS with Unicode fallback ✅ Right-aligned timing information ✅ Color-coded status icons and output ✅ Issues as expandable sub-nodes ✅ Enhanced start/end messages ✅ Thread-safe concurrent test execution
Implementing progress bar with live update
There was a problem hiding this comment.
Bugbot free trial expires on August 7, 2025
Learn more in the Cursor dashboard.
| var symbolCounts: [String: Int] = [ | ||
| "pass": 0, | ||
| "fail": 0, | ||
| "passWithKnownIssues": 0, | ||
| "passWithWarnings": 0, | ||
| "skip": 0, | ||
| "difference": 0, | ||
| "warning": 0, | ||
| "details": 0, | ||
| "attachment": 0 | ||
| ] |
There was a problem hiding this comment.
I think we should strive to avoid a stringly-typed Dictionary for this purpose. Could these be broken out into discrete stored properties?
| let progressBarDelay: UInt64 = 1_000_000 // 1ms in nanoseconds | ||
| } | ||
|
|
||
| private static let _livePhaseState = Locked(rawValue: LivePhaseState()) |
There was a problem hiding this comment.
Why do we need a separate lock, other than _context above, for this? And why does this one need to be static?
| } | ||
|
|
||
| private func shouldShowProgressBar(currentInstant: Test.Clock.Instant) -> Bool { | ||
| return Self._livePhaseState.withLock { state in |
There was a problem hiding this comment.
Several of the methods in/around this one obtain the lock using Self._livePhaseState.withLock { ... } but they appear to be called from handle(_:in:) and in some situations, it looks like more than one function obtains the lock and then releases it in succession.
Could this instead be structured so that it obtains the lock just once and then defers any writes until after the critical zone? My main concern is that each event is handled atomically; parallelization could mean that two or more events interleave
| handleHierarchicalEvent(event, in: eventContext) | ||
| } else { | ||
| // Fallback to regular console output | ||
| let consoleRecorder = Event.ConsoleOutputRecorder(options: options.base, writingUsing: write) |
There was a problem hiding this comment.
Oh, I see now this is where the current Event.ConsoleOutputRecorder still gets used. It makes me a bit nervous for this to be placed so deep within the new code; I'd be more comfortable basically choosing which output recorder to use in EntryPoint.swift and having the two recorders act as peers of one another.
- Add experimental AdvancedConsoleOutputRecorder activated via environment variable - Implement clean skeleton structure for incremental PR development - Fix terminal width hardcoding with 80-char safe fallback - Follow HumanReadableOutputRecorder delegation pattern - Update style guide compliance (80-char comment wrapping) - Re-enable AttachmentTests and disable slow demo test suites - Remove Foundation dependencies and signal handling - Prepare foundation for PR #1 (Skeleton), PR #2 (Hierarchy), PR #3 (Progress)
- Update to latest main branch from upstream/main - Integrate new ABI version handling and entry point improvements - Preserve AdvancedConsoleOutputRecorder skeleton implementation - Ready for first PR submission
Adds an advanced, two-phase console reporter with live progress updates and a final hierarchical summary.
Motivation:
The default console output for swift test is a static log, which can present several challenges for developers, especially in large, parallel test suites:
This new console reporter is designed to solve these problems by providing both immediate, real-time feedback during the test run and a comprehensive, structured summary at the end.
Modifications:
Checklist: