Fix MSTEST0068 build errors: replace CollectionAssert with Assert.AreSequenceEqual#8815
Fix MSTEST0068 build errors: replace CollectionAssert with Assert.AreSequenceEqual#8815Evangelink wants to merge 1 commit into
Conversation
Replace CollectionAssert.AreEqual with Assert.AreSequenceEqual and CollectionAssert.AreEquivalent with Assert.AreSequenceEqual(..., SequenceOrder.InAnyOrder) in the affected unit-test files. All call sites operate on string collections where the suggested mapping is semantically equivalent. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR updates unit tests across Microsoft.Testing.Platform and Microsoft.Testing.Extensions to address MSTEST0068 by replacing CollectionAssert collection comparisons with the newer Assert.AreSequenceEqual APIs (including SequenceOrder.InAnyOrder where the previous intent was order-insensitive equivalence).
Changes:
- Replaced
CollectionAssert.AreEqual(...)withAssert.AreSequenceEqual(...)in several unit tests validating argument/option sequences. - Replaced
CollectionAssert.AreEquivalent(...)withAssert.AreSequenceEqual(..., SequenceOrder.InAnyOrder)where ordering is not significant. - Standardized collection assertion usage to align with the
CollectionAssertToAssertAnalyzermapping and eliminate analyzer build breaks.
Show a summary per file
| File | Description |
|---|---|
| test/UnitTests/Microsoft.Testing.Platform.UnitTests/Configuration/JsonCommandLineOptionsTests.cs | Swaps CollectionAssert.AreEqual for Assert.AreSequenceEqual when validating parsed option argument lists. |
| test/UnitTests/Microsoft.Testing.Platform.UnitTests/Configuration/CommandLineConfigurationExtensionsTests.cs | Uses Assert.AreSequenceEqual for command-line argument arrays returned from configuration helpers. |
| test/UnitTests/Microsoft.Testing.Platform.UnitTests/Services/CurrentTestApplicationModuleInfoTests.cs | Updates argument sequence assertions to Assert.AreSequenceEqual for executable argument construction scenarios. |
| test/UnitTests/Microsoft.Testing.Extensions.UnitTests/AzureDevOpsArtifactUploaderTests.cs | Replaces AreEquivalent/AreEqual with AreSequenceEqual, using SequenceOrder.InAnyOrder for tag assertions. |
| test/UnitTests/Microsoft.Testing.Extensions.UnitTests/AzureDevOpsLivePublishingTests.cs | Updates ordered event sequence assertion to Assert.AreSequenceEqual. |
| test/UnitTests/Microsoft.Testing.Extensions.UnitTests/CrashDumpTests.cs | Updates dump-path sequence assertions to Assert.AreSequenceEqual. |
| test/UnitTests/Microsoft.Testing.Extensions.UnitTests/TrxStreamingSerializerTests.cs | Updates category sequence assertion to Assert.AreSequenceEqual. |
Copilot's findings
- Files reviewed: 7/7 changed files
- Comments generated: 0
|
Superseded: the fix was pushed directly to the Maestro branch on #8811 instead. |
Evangelink
left a comment
Evangelink
left a comment
There was a problem hiding this comment.
Code Review — PR #8815: Fix MSTEST0068 (Replace CollectionAssert with Assert.AreSequenceEqual)
Verdict: ✅ All 21 dimensions clean — no issues found.
Summary
This is a pure mechanical fix that applies the MSTEST0068 analyzer's suggested replacements at 31 call sites across 7 test files. No production code is touched.
| Mapping applied | Semantic equivalence |
|---|---|
CollectionAssert.AreEqual(expected, actual) → Assert.AreSequenceEqual(expected, actual) |
✅ Ordered comparison preserved |
CollectionAssert.AreEquivalent(expected, actual) → Assert.AreSequenceEqual(expected, actual, SequenceOrder.InAnyOrder) |
✅ Unordered / multiset semantics preserved |
Parameter order (expected first, actual second) is consistent between the old and new APIs — confirmed against Assert.AreSequenceEqual.cs. No argument swaps introduced.
All changed call sites operate on string[] with default equality — no custom comparers were in play, so no information is lost in the migration. The two AreEquivalent → InAnyOrder conversions correctly preserve the unordered semantics that were intended.
The PR description notes local verification with -warnaserror passing at 0 errors / 0 warnings — consistent with the change being a pure compliant migration.
No blocking or major issues across any of the 21 review dimensions.
Generated by Expert Code Review (on open) for issue #8815 · sonnet46 1.4M
Builds were failing with 99
MSTEST0068errors (e.g. on #8811) after the newCollectionAssertToAssertAnalyzerstarted reporting against existing call sites in our own unit tests.This PR applies the analyzer's suggested fix at every flagged location:
CollectionAssert.AreEqual(a, b)→Assert.AreSequenceEqual(a, b)CollectionAssert.AreEquivalent(a, b)→Assert.AreSequenceEqual(a, b, SequenceOrder.InAnyOrder)I reviewed each of the 31 distinct call sites individually — all of them operate on simple
string[]collections where the suggested mapping is semantically equivalent (default equality, ordered vs. multiset semantics preserved), so no analyzer suggestion needed to be opted out and no follow-up issue is required.Files touched:
test/UnitTests/Microsoft.Testing.Platform.UnitTests/Configuration/JsonCommandLineOptionsTests.cstest/UnitTests/Microsoft.Testing.Platform.UnitTests/Configuration/CommandLineConfigurationExtensionsTests.cstest/UnitTests/Microsoft.Testing.Platform.UnitTests/Services/CurrentTestApplicationModuleInfoTests.cstest/UnitTests/Microsoft.Testing.Extensions.UnitTests/AzureDevOpsArtifactUploaderTests.cstest/UnitTests/Microsoft.Testing.Extensions.UnitTests/AzureDevOpsLivePublishingTests.cstest/UnitTests/Microsoft.Testing.Extensions.UnitTests/CrashDumpTests.cstest/UnitTests/Microsoft.Testing.Extensions.UnitTests/TrxStreamingSerializerTests.csVerified locally with:
Both succeed with 0 errors / 0 warnings.