Skip to content
123 changes: 77 additions & 46 deletions tests/dotnet-test/migrate-mstest-v1v2-to-v3/eval.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -31,8 +31,8 @@ scenarios:

- name: "Migrate MSTest v2 NuGet project to v3"
prompt: |
My test project uses MSTest.TestFramework 2.2.10 and MSTest.TestAdapter 2.2.10 on .NET 6.
I want to upgrade to MSTest v3. What breaking changes should I expect?
I want to upgrade my MSTest v2 test project to the next major version.
Can you review my project and tell me what I need to change?
setup:
files:
- path: "TestProject.csproj"
Expand All @@ -41,15 +41,14 @@ scenarios:
source: "fixtures/v2-nuget/UserServiceTests.cs"
assertions:
- type: "output_matches"
pattern: "(2\\.2\\.10|v2|version 2)"
pattern: "(3\\.[0-9]+|v3|version 3|MSTest\\.Sdk)"
- type: "output_matches"
pattern: "(3\\.[0-9]+|v3|version 3)"
pattern: "(Assert\\.(AreEqual|AreNotEqual)(<[^>]+>)?|object overload|overload removal|remove[ds]? the object overload|generic type parameter[s]?)"
rubric:
- "Identifies the project as MSTest v2 from the 2.2.10 package versions"
- "Recommends updating MSTest packages to 3.x or switching to the MSTest metapackage"
- "Warns about Assert.AreEqual/AreNotEqual object overload removal"
- "Mentions DataRow constructor changes and strict type matching"
- "Mentions timeout behavior unification across .NET Core and .NET Framework"
- "Recommends the MSTest metapackage or MSTest.Sdk as the upgrade path, not just bumping individual package versions"
- "Warns about the Assert.AreEqual/AreNotEqual object overload removal visible in UserServiceTests.cs"
- "Identifies the DataRow 1L (long) to int type mismatch and explains that v3 enforces strict type matching"
Comment thread
Evangelink marked this conversation as resolved.
Outdated
- "Mentions that Microsoft.NET.Test.Sdk must be kept as a dependency (or notes MSTest.Sdk provides it automatically)"
timeout: 240

# ============================================================================
Expand All @@ -58,9 +57,9 @@ scenarios:

- name: "Fix Assert.AreEqual object overload errors after v3 upgrade"
prompt: |
I just upgraded to MSTest v3 and I'm getting compilation errors like:
"error CS1503: Argument 1: cannot convert from 'object' to 'string'"
on Assert.AreEqual calls. My tests compare objects. How do I fix this?
After updating my MSTest NuGet packages, several of my tests no longer compile.
I'm seeing errors on various Assert calls. Can you review my test file and fix
the compilation issues?
setup:
files:
- path: "TestProject.csproj"
Expand All @@ -83,39 +82,54 @@ scenarios:
public class ComparisonTests
{
[TestMethod]
public void CompareObjects_AreEqual()
public void CompareStrings_AreEqual()
{
object expected = GetExpected();
object actual = GetActual();
object expected = GetExpectedName();
object actual = GetActualName();
Assert.AreEqual(expected, actual);
}

[TestMethod]
public void CompareObjects_AreNotEqual()
public void CompareIntegers_AreNotEqual()
{
object a = "hello";
object b = "world";
object a = GetCount();
object b = GetOtherCount();
Assert.AreNotEqual(a, b);
}

[TestMethod]
public void CompareReferences_AreSame()
{
object obj = new object();
Assert.AreSame(obj, obj);
var svc = GetService();
Assert.AreSame(svc, svc);
}

private static object GetExpected() => 42;
private static object GetActual() => 42;
[TestMethod]
public void MixedComparison_DifferentTypes()
{
object result = Compute();
Assert.AreEqual(42, result);
Assert.AreNotEqual(null, result);
}

private static object GetExpectedName() => "Alice";
private static object GetActualName() => "Alice";
private static object GetCount() => 1;
private static object GetOtherCount() => 2;
private static IService GetService() => new ServiceImpl();
private static object Compute() => 42;
}

public interface IService { }
public class ServiceImpl : IService { }
assertions:
- type: "output_matches"
pattern: "(generic|AreEqual<|<T>|type.?param)"
rubric:
- "Explains that MSTest v3 removed the Assert.AreEqual(object, object) overload"
- "Recommends adding explicit generic type parameters: Assert.AreEqual<T>(expected, actual)"
- "Applies the same fix pattern to AreNotEqual, AreSame, and AreNotSame"
- "Does not suggest downgrading to MSTest v2 as a solution"
- "Explains that MSTest v3 removed the non-generic Assert.AreEqual(object, object) overload family"
- "Recommends adding explicit generic type parameters and chooses the correct type for each case (e.g., Assert.AreEqual<object> for mixed types, Assert.AreSame<IService> or the concrete type for interface references)"
- "Applies the fix to AreNotEqual and AreSame calls, not just AreEqual"
- "Does not suggest downgrading MSTest as a solution"
timeout: 180

# ============================================================================
Expand All @@ -124,8 +138,9 @@ scenarios:

- name: "Migrate from .testsettings to .runsettings"
prompt: |
My MSTest project has a .testsettings file that configures test deployment and timeout.
After upgrading to MSTest v3, it seems to be ignored. How do I migrate?
My MSTest project has a .testsettings file that configures test deployment, timeout,
and a code coverage data collector. After a package update, the settings seem to be
ignored. How do I migrate this configuration?
setup:
files:
- path: "TestProject.csproj"
Expand Down Expand Up @@ -154,6 +169,12 @@ scenarios:
<Properties>
<Property name="TestTimeout" value="30000" />
</Properties>
<AgentRule name="LocalMachineDefaultRole">
<DataCollectors>
<DataCollector uri="datacollector://microsoft/CodeCoverage/1.0"
assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector" />
</DataCollectors>
</AgentRule>
</TestSettings>
assertions:
- type: "output_matches"
Expand All @@ -162,9 +183,10 @@ scenarios:
pattern: "(testsettings|legacy|no longer supported)"
rubric:
- "Explains that .testsettings and LegacySettings are no longer supported in MSTest v3"
- "Provides guidance on creating a .runsettings file as a replacement"
- "Shows how to configure timeout and other settings in .runsettings XML format"
- "Does not suggest keeping the .testsettings file alongside .runsettings"
- "Provides a .runsettings file that maps the TestTimeout to <MSTest><TestTimeout> (per-test), not to <TestSessionTimeout>"
- "Maps the code coverage data collector into the <DataCollectionRunSettings><DataCollectors> section of .runsettings"
- "Recommends deleting the .testsettings file entirely rather than keeping it alongside .runsettings"
- "Notes that AssemblyResolution settings can be removed as they are not needed in modern .NET"
timeout: 180

# ============================================================================
Expand All @@ -173,9 +195,9 @@ scenarios:

- name: "Fix DataRow type mismatch errors after v3 upgrade"
prompt: |
After upgrading to MSTest v3, many of my data-driven tests fail to compile with errors
about DataRow constructors. I have tests with lots of parameters and some implicit
type conversions. What changed and how do I fix it?
After updating my test project's NuGet packages, several data-driven tests
no longer compile. The errors are on the DataRow attributes. Can you review
my test file and fix the issues?
setup:
files:
- path: "TestProject.csproj"
Expand Down Expand Up @@ -205,6 +227,14 @@ scenarios:
Assert.IsNotNull(name);
}

[TestMethod]
[DataRow(10.0, 3.5f)]
[DataRow(20.0, 7.2f)]
public void CalculateDiscount(float price, float rate)
{
Assert.IsTrue(rate > 0);
}

[TestMethod]
[DataRow(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17)]
public void ManyParameters(int a, int b, int c, int d, int e, int f,
Expand All @@ -216,12 +246,12 @@ scenarios:
}
assertions:
- type: "output_matches"
pattern: "(DataRow|type.?match|constructor|16|param)"
pattern: "(DataRow|type.?match|constructor|strict)"
rubric:
- "Explains that MSTest v3 requires DataRow values to match parameter types exactly"
- "Identifies the 1L (long) vs int mismatch and recommends fixing to 1 (int)"
- "Explains the 16-parameter limit on DataRow constructors and suggests refactoring or wrapping in an array"
- "Does not suggest downgrading as a fix"
- "Explains that MSTest v3 enforces strict type matching in DataRow -- implicit conversions that worked in v2 now fail"
- "Fixes the long-to-int mismatch (1L → 1) and the double-to-float mismatch (10.0 → 10.0f)"
- "Explains the 16-parameter constructor limit and suggests refactoring; if the project is on an earlier 3.x release, it may also suggest updating to the latest 3.x where the limitation may be resolved"
- "Does not suggest downgrading MSTest as a fix"
timeout: 240

# ============================================================================
Expand Down Expand Up @@ -266,15 +296,15 @@ scenarios:

- name: "Handle dropped target framework during v3 migration"
prompt: |
My test project targets .NET 5.0 and uses MSTest v2. I want to upgrade to MSTest v3.
Will there be any framework compatibility issues?
My test project multi-targets several frameworks and uses MSTest v2.
I want to upgrade to MSTest v3. Will I run into compatibility issues?
setup:
files:
- path: "TestProject.csproj"
content: |
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<TargetFrameworks>net5.0;net462;netcoreapp3.1</TargetFrameworks>
<IsPackable>false</IsPackable>
</PropertyGroup>
<ItemGroup>
Expand All @@ -285,11 +315,12 @@ scenarios:
</Project>
assertions:
- type: "output_matches"
pattern: "(net5\\.0|dropped|unsupported|net6\\.0|net8\\.0)"
pattern: "(net5\\.0|dropped|unsupported|net8\\.0)"
Comment thread
Evangelink marked this conversation as resolved.
rubric:
- "Identifies that .NET 5.0 is no longer supported by MSTest v3"
- "Recommends upgrading to .NET 6.0 or later (preferably .NET 8.0 as a current LTS)"
- "Does not suggest staying on .NET 5.0 with MSTest v3"
- "Identifies that .NET 5.0 is dropped in MSTest v3 and recommends replacing it with .NET 8.0 (LTS) or .NET 6+"
- "Correctly states that .NET Framework 4.6.2 is still supported by MSTest v3 and does not need to change"
- "Correctly states that .NET Core 3.1 is still supported by MSTest v3 and does not need to change"
- "Does not recommend upgrading all TFMs indiscriminately -- only the unsupported one"
timeout: 180

# ============================================================================
Expand Down