Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[file-diet] Refactor MtpServerClient.cs (581 lines) into focused partial files

Closed
#11,918 0 comments 1 reaction 2 assignees View on GitHub

Maintainers usually reply within 1 day

@Evangelink is already working on this.

Since Oct 13, 2026.

  • #11919 by @copilot-swe-agent — merged

Assessment

This issue has not been assessed yet.

Description

type/automation type/tech-debt
Overview

The file src/Platform/Microsoft.Testing.Platform.ServerMode.Client.Sources/Client/MtpServerClient.cs has grown to 581 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.Platform.ServerMode.Client.Sources/Client/MtpServerClient.cs
  • Size: 581 lines
  • Language: C#
Structural Analysis

MtpServerClient is the internal sealed class implementation of IMtpServerClient, a client over MtpJsonRpcConnection used to talk to an MTP server. Based on a bounded sample (first 100 lines plus a member-signature scan), it contains three distinguishable groups of responsibility:

  1. Construction / lifecycle: constructors, Launch, LaunchAsync, LaunchInProcessAsync, InitializeAsync, Dispose, DetachHandlers, EnsureStarted — connecting to and tearing down the underlying transport/process.
  2. Test execution: DiscoverCoreAsync, RunCoreAsync, OnServerRequestAsync — sending discovery/run requests and handling server-initiated requests.
  3. Event/notification plumbing: OnNotificationReceived, RaiseTestNodesUpdated, RaiseLog, RaiseTelemetry, RaiseAttachments — translating raw JSON-RPC notifications into the public TestNodesUpdated, LogReceived, TelemetryReceived, AttachmentsReceived events.

This file is internal sealed, which makes a partial class split across files a natural, low-risk option for a single-project source-included package (.Sources suffix suggests it is distributed as source, so public/internal surface for consumers outside this project must stay unchanged).

Refactoring Strategy
Proposed File Splits

Based on the bounded structural sample, investigate these proposed splits. Confirm their safety during implementation preflight before moving code — treat these as provisional until verified against the full file body, its callers, and existing tests:

  1. MtpServerClient.cs (retained)

    • Contents: Class declaration, fields, constructors, public events, properties (ServerRequestHandler, ProcessId, ServerExitCode, Capabilities), Launch/LaunchAsync/LaunchInProcessAsync/InitializeAsync, Dispose, DetachHandlers, EnsureStarted.
    • Responsibility: Client identity, connection lifecycle, and startup/teardown.
  2. MtpServerClient.Execution.cs (new partial)

    • Contents: DiscoverCoreAsync, RunCoreAsync, OnServerRequestAsync.
    • Responsibility: Sending discovery/run requests to the server and responding to server-initiated requests.
  3. MtpServerClient.Notifications.cs (new partial)

    • Contents: OnNotificationReceived, RaiseTestNodesUpdated, RaiseLog, RaiseTelemetry, RaiseAttachments.
    • Responsibility: Deserializing JSON-RPC notification payloads and raising the corresponding public events.
Implementation Guidelines
  1. Establish Equivalence: Follow .github/skills/behavior-preserving-refactor/SKILL.md. Before editing, read the complete affected bodies, inventory baseline behavior and relevant tests, and identify distinguishing cases.
  2. Preserve Selection and Evaluation: Keep iteration order, short-circuit evaluation, exact type selection, first/last-match semantics, defaults, exceptions, and side effects. Cover reachable duplicate and malformed inputs; similar-looking helpers are not automatically interchangeable.
  3. Trace All Consumers: Check partial declarations, source-linked consumers, owning/consuming project includes, target-framework guards, and tracked public/internal API surfaces. Keep names, accessibility, attributes, and native interop contracts unchanged. Because this file lives under a .Sources project, verify how it is included (source link vs. compile item) by every consuming project and ensure all new partial files are included identically.
  4. Move Before Modernizing: Move bodies unchanged first, one coherent responsibility at a time. Preserve allocation and performance behavior on hot paths; do not mix adjacent modernization or bug fixes into the split.
  5. Use Focused Checks: Run the smallest affected project/TFM builds and relevant tests before and after each coherent split. Add distinguishing equivalence cases where coverage is missing; a pure file move does not require the full solution. Report exact checks and outcomes, including unavailable checks.
  6. Surface Constraints: Measure resulting line counts. If a safe structural split cannot meet the size goal without changing semantics, report the remaining size and blocker rather than forcing behavior changes.
Acceptance Criteria
  • Original file is split into focused modules
  • Each new file is under 300 lines, or a concrete behavior-preservation blocker and remaining size are reported
  • Baseline semantics, including reachable duplicate/malformed cases and evaluation order, are preserved by focused equivalence checks
  • Relevant builds and tests pass for affected consumers/TFMs; exact checks and any validation gaps are reported
  • Public and tracked internal API contracts, attributes, and conditional compilation are preserved
  • Project includes, source links, and package layout still include the moved code for every affected consumer

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 · 39.6 AIC · ⌖ 5.19 AIC · ⊞ 13K · [◷]( · ◷)

  • expires on Oct 15, 2026, 7:01 PM UTC
Dominant language
C#
Stars
1k
Forks
314
Avg merge
8h 49m
Merged PRs (30d)
442

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/testfx

All issues in microsoft/testfx

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.