/writing-mstest-tests

name: writing-mstest-tests
description: >
  Write, create, modernize, or fix comprehensive MSTest unit tests with MSTest 3.x/4.x APIs.
  USE FOR: write, create, review, or modernize MSTest tests and assertions,
  better MSTest assertion than Assert.IsTrue, replace hard cast with IsInstanceOfType,
  MSTest assertion APIs (Contains, ContainsSingle, HasCount, IsEmpty, IsNotEmpty, DoesNotContain,
  AreSame, IsNull, StartsWith, EndsWith, MatchesRegex, IsGreaterThan, IsLessThan, IsInRange),
  swapped/reversed Assert.AreEqual args (Expected/Actual backwards),
  replace ExpectedException with Assert.Throws,
  data-driven (DataRow, DynamicData, ValueTuples),
  lifecycle (TestInitialize, TestCleanup, TestContext),
  async and cancellation tests, conditional execution/retry/cleanup (OSCondition, Retry),
  parallelization (Parallelize/DoNotParallelize), MSTest.Sdk setup, MSTESTxxxx analyzer fixes.
  DO NOT USE FOR: test quality audits (use test-anti-patterns),
  running tests (use run-tests), MSTest version migration (use migrate-mstest skills),
  xUnit/NUnit/TUnit, or non-.NET languages.
license: MIT

Writing MSTest Tests

Help users write effective, modern unit tests with MSTest 3.x/4.x using current APIs and best practices.

When to Use

• User wants to write new MSTest unit tests
• User wants to improve or modernize existing MSTest tests by implementing concrete fixes
• User asks about MSTest assertion APIs, data-driven patterns, or test lifecycle
• User asks to replace `Assert.IsTrue` with more specific assertions (collections, nulls, types, comparisons)
• User asks to replace hard casts with type-checking assertions in tests
• User needs help fixing a specific MSTest test bug or failing assertion
• User asks to fix swapped `Assert.AreEqual` argument order (expected first, actual second)
• User asks to convert `DynamicData` from `IEnumerable<object[]>` to ValueTuple-based data
• User asks to fix or understand an MSTest analyzer diagnostic (an `MSTESTxxxx` warning/error)

When Not to Use

• User needs a test quality audit, anti-pattern detection, or flaky-test investigation (use `test-anti-patterns`)
• User needs to run or execute tests (use the `run-tests` skill)
• User needs to upgrade from MSTest v1/v2 to v3 (use `migrate-mstest-v1v2-to-v3`)
• User needs to upgrade from MSTest v3 to v4 (use `migrate-mstest-v3-to-v4`)
• User needs CI/CD pipeline configuration
• User is using xUnit, NUnit, or TUnit (not MSTest)

Inputs

| Input | Required | Description | |-------|----------|-------------| | Code under test | No | The production code to be tested | | Existing test code | No | Current tests to fix, update, or modernize | | Test scenario description | No | What behavior the user wants to test |

Response Guidelines

• **Specific API or pattern questions** (assertions, data-driven, lifecycle): Jump directly to the relevant workflow step. Do not follow the full workflow.
• **Write new tests from scratch**: Follow the full workflow.
• **Review and fix existing tests**: Fix only the issues present. Do not add unrelated improvements.

Workflow

Step 1: Determine project setup

Check the test project for MSTest version and configuration:

• If using `MSTest.Sdk` (`<Sdk Name="MSTest.Sdk">`): modern setup, all features available
• If using `MSTest` metapackage: modern setup (MSTest 3.x+)
• If using `MSTest.TestFramework` + `MSTest.TestAdapter`: check version for feature availability

Recommend MSTest.Sdk or the MSTest metapackage for new projects:

<!-- Option 1: MSTest SDK (simplest, recommended for new projects) -->
<Project Sdk="MSTest.Sdk">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
</Project>

When using `MSTest.Sdk`, put the version in `global.json` instead of the project file so all test projects get bumped together:

{
  "msbuild-sdks": {
    "MSTest.Sdk": "3.8.2"
  }
}

<!-- Option 2: MSTest metapackage -->
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="MSTest" Version="3.8.2" />
  </ItemGroup>
</Project>

Step 2: Write test classes following conventions

Apply these structural conventions:

• **Seal test classes** with `sealed` for performance and design clarity
• Use `[TestClass]` on the class and `[TestMethod]` on test methods
• Follow the **Arrange-Act-Assert** (AAA) pattern
• Name tests using `MethodName_Scenario_ExpectedBehavior`
• Use separate test projects with naming convention `[ProjectName].Tests`

[TestClass]
public sealed class OrderServiceTests
{
    [TestMethod]
    public void CalculateTotal_WithDiscount_ReturnsReducedPrice()
    {
        // Arrange
        var service = new OrderService();
        var order = new Order { Price = 100m, DiscountPercent = 10 };

        // Act
        var total = service.CalculateTotal(order);

        // Assert
        Assert.AreEqual(90m, total);
    }
}

Step 3: Use modern assertion APIs

Pick the most specific assertion for each test scenario. More specific assertions produce better failure messages and make the test's intent clear:

| What you are testing | Assertion | |---|---| | Two values are equal | `Assert.AreEqual(expected, actual)` | | Same object instance (reference identity) | `Assert.AreSame(expected, actual)` | | Value is null | `Assert.IsNull(value)` | | Value is not null | `Assert.IsNotNull(value)` | | Collection is empty | `Assert.IsEmpty(collection)` | | Collection is not empty | `Assert.IsNotEmpty(collection)` | | Collection has exactly N items | `Assert.HasCount(N, collection)` | | Collection contains an item | `Assert.Contains(item, collection)` | | Collection does not contain an item | `Assert.DoesNotContain(item, collection)` | | Object is a specific type | `Assert.IsInstanceOfType<T>(value)` | | Code throws an exception | `Assert.ThrowsExactly<T>(() => ...)` |

Prefer `Assert` class meth