/migrate-mstest-v3-to-v4

name: migrate-mstest-v3-to-v4
description: >
  Use this skill before answering, planning, or editing any MSTest 3.x-to-4.x
  upgrade or post-upgrade failure. Triggers include "MSTest v4 breaking
  changes"; CS0507/CS0103/CS1061/CS1615; ExecuteAsync, CallerInfo, DisplayName,
  or custom TestMethodAttribute; ClassCleanupBehavior; ContainsKey;
  ThrowsExactly or ExpectedException; IsInstanceOfType out parameters;
  TestTimeout.Infinite; ManagedType; net6/net7 compatibility; TestCase.Id
  history; TestName in ClassInitialize; TreatDiscoveryWarningsAsErrors;
  discovery errors after a clean build; and MSTest.Sdk/MTP or vstest.console
  discovery changes. Do not use for v1/v2-to-v3 leftovers, framework
  conversion, runner-only migration, or a general .NET upgrade.
license: MIT

MSTest v3 -> v4 Migration

Migrate a test project from MSTest v3 to MSTest v4. The outcome is a project using MSTest v4 that builds cleanly, passes tests, and accounts for every source-incompatible and behavioral change. MSTest v4 is **not binary compatible** with MSTest v3 -- any library compiled against v3 must be recompiled against v4.

First Action

Inspect the supplied project and source before searching the web or answering from memory. Classify the request as a focused source fix, runtime behavior change, CI discovery issue, compatibility question, or full migration, then follow the matching row below. A clean compile does not exclude this skill: discovery failures, `TestContext` lifecycle exceptions, and test-history changes are runtime migration failures.

When to Use

• Upgrading `MSTest.TestFramework`, `MSTest.TestAdapter`, or `MSTest` metapackage from 3.x to 4.x
• Upgrading `MSTest.Sdk` from 3.x to 4.x
• Fixing build errors after updating to MSTest v4 packages
• Resolving behavioral changes in test execution after upgrading to MSTest v4
• Updating custom `TestMethodAttribute` or `ConditionBaseAttribute` implementations for v4

When Not to Use

• The project already uses MSTest v4 and builds cleanly -- migration is done
• Upgrading from MSTest v1 or v2 -- use `migrate-mstest-v1v2-to-v3` first, then return here
• The project does not use MSTest
• Migrating between test frameworks (e.g., MSTest to xUnit or NUnit)

Inputs

| Input | Required | Description | |-------|----------|-------------| | Project or solution path | No | The `.csproj`, `.sln`, or `.slnx` entry point containing MSTest test projects. **Discover it yourself** by globbing the working directory; ask only when nothing is found or the choice is genuinely ambiguous | | Build command | No | How to build (e.g., `dotnet build`, a repo build script). Auto-detect if not provided | | Test command | No | How to run tests (e.g., `dotnet test`). Auto-detect if not provided |

Decisions That Change the Result

| Detected request or state | Required action | |---|---| | Files are supplied in the current workspace | Search there and open the literal returned paths. The skill directory is not the project directory. If one tool rejects a valid path, retry with another available reader/editor; do not ask the user for a path you can discover. | | User asks to apply changes to supplied files: "fix my project/files", "please update this source", "make the changes", or "then build and run" | Edit every affected occurrence. Run the narrowest meaningful build/test command against the actual package version; skill activation is not a reason to stop at advice. | | User asks "what should I expect?", "how do I fix these changes?", for compatibility advice, or for a plan | Answer directly from the actual project state even when source is visible. Keep a single-symptom answer focused; include only adjacent risks that change the decision. | | Unsupported TFM in a full migration | Update the TFM first, then update MSTest packages, then fix source breaks. Do not bury this order in a release-note inventory. | | Custom `TestMethodAttribute` subclass | Treat `ExecuteAsync`, CallerInfo propagation, display-name handling, and the subclass's retry/result semantics as one coupled migration. Fix the actual class, not a placeholder example. | | `MSTest.Sdk` v4 source/API errors (`ManagedType`, `TestTimeout`, `Contains`) | Give the exact source replacements, then add the adjacent runner warning: MTP mode no longer supplies `Microsoft.NET.Test.Sdk`; add it only if VSTest discovery is still required. | | `MSTest.Sdk` v4 plus `vstest.console` | This is a v4 change: MTP mode no longer brings `Microsoft.NET.Test.Sdk`. Keep MTP and add that package for transitional VSTest discovery, opt into `UseVSTest`, or migrate CI to `dotnet test`; state which runner the choice preserves. |

Response Guidelines

• **Always identify the current version first**: Before recommending any migration steps, explicitly state the current MSTest version detected in the project (e.g., "Your project uses MSTest v3 (3.8.0)"). This confirms you've read the project files and grounds the migration advice.
• **Resolve, do not assume, the target version**: When the user asks for "latest", query the project's configured package source and select the latest stable MSTest v4 version available at execution time. Never copy the example version from this skill into the result without checking it. Keep all MSTest packages on the same resolved version.
• **Focused fix requests** (user has specific compilation errors after upgrading): Address only the relevant breaking changes from Step 3. Make edits only when the requested deliverable is a source change; "how do I fix these?" remains an answer request. **Always provide concrete fixed code** using the user's actual types and method names. If the fixture still references v3, do not claim that a green v3 build verifies v4 compatibility; either update packages when requested or state the verification boundary. For custom `TestMethodAttribute` subclasses, show the full fixed class including CallerInfo propagation to the base constructor. Mention any related a