[file-diet] Refactor AzureDevOpsTestResultsPublisher.cs (578 lines) into focused partial-class files

Overview

The file src/Platform/Microsoft.Testing.Extensions.AzureDevOpsReport/AzureDevOpsTestResultsPublisher.cs has grown to 578 lines, making it harder to navigate and maintain. This task involves refactoring it into smaller, more focused files.

Current State

• File: src/Platform/Microsoft.Testing.Extensions.AzureDevOpsReport/AzureDevOpsTestResultsPublisher.cs
• Size: 578 lines
• Language: C#

Refactoring Strategy

Proposed File Splits

Following the existing partial-class convention already used for this type, split the remaining logic into additional partial-class files:

1. AzureDevOpsTestResultsPublisher.InProcessRetryAggregation.cs

   • Contents: ConsumeAsync, AggregateInProcessRetryAttempt, nested InProcessRetrySequence class, DrainIncompleteInProcessRetrySequences, and the related _inProcessRetrySequences / _inProcessRetryAttemptsLock fields.
   • Responsibility: Coalescing in-process test retry attempts into a single result before they are queued for publishing.

2. AzureDevOpsTestResultsPublisher.Output.cs

   • Contents: WarnAsync, DisplayAsync, DisplayCoreAsync, TryLogWarning.
   • Responsibility: Output-device/logger interaction for warnings and diagnostic messages surfaced to the user.

3. AzureDevOpsTestResultsPublisher.SessionLifetime.cs

   • Contents: OnTestSessionStartingAsync, OnTestSessionFinishingAsync, Dispose, IsEnabledAsync.
   • Responsibility: ITestSessionLifetimeHandler implementation — orchestrating startup, coordinated flush/finalization, and teardown of the publisher across the test session.

4. AzureDevOpsTestResultsPublisher.cs (remaining)

   • Contents: Fields, constructors, and IDataConsumer/IOutputDeviceDataProducer metadata properties (Uid, Version, DisplayName, Description, DataTypesConsumed, CurrentRunId, RunId).
   • Responsibility: Core type definition, dependency wiring, and metadata surface.

Implementation Guidelines

1. Preserve Behavior: All existing functionality must work identically after the split
2. Maintain Public API: Keep exported/public symbols accessible with the same names
3. Update Imports: Fix all import paths throughout the codebase
4. Test After Each Split: Run the test suite after each incremental change
5. One File at a Time: Split one module at a time to make review easier

Acceptance Criteria

• Original file is split into focused modules
• Each new file is under 300 lines
• All tests pass after refactoring
• No breaking changes to public API
• All import paths updated correctly

Priority: Medium
Effort: Small
Expected Impact: Improved code navigability, easier testing, reduced merge conflicts

🤖 Automated content by GitHub Copilot. Generated by the Daily File Diet workflow. · copilot · auto · 48.4 AIC · ⌖ 5.69 AIC · ⊞ 12.1K · [◷]( · ◷)

• expires on Sep 26, 2026, 6:57 PM UTC