Add Span<T>/Memory<T> overloads to Assert.HasCount (and extend MSTEST0037)

[Evangelink]

Summary

Assert.HasCount<T> today only accepts IEnumerable<T>. With Span<T>/ReadOnlySpan<T>/Memory<T>/ReadOnlyMemory<T> being pervasive in modern .NET (System.Buffers, pipelines, parsers, low-allocation APIs), users repeatedly hit a gap right next to sites that MSTEST0037 happily rewrites.

Repro

In dotnet/sdk PR #54766, turning on MSTestAnalysisMode=Recommended flagged ~25 length/count assertions in ArrayBufferWriterTests.cs. All the IEnumerable/ArraySegment/array cases were auto-fixed to Assert.HasCount. But sites like:

csharp Assert.AreEqual(written.Length, transientSpan.Length);

cannot be fixed today because there's no HasCount overload that accepts a Span<T> or ReadOnlySpan<T>. The analyzer correctly skips them, but the result is an inconsistent UX: identical-looking call sites get different treatment based on whether the value is an IEnumerable or a Span.

Proposal

1. Add overloads to Assert.Count.cs (and their interpolated-message variants):

   csharp public static void HasCount<T>(int expected, ReadOnlySpan<T> span); public static void HasCount<T>(int expected, Span<T> span); public static void HasCount<T>(int expected, ReadOnlyMemory<T> memory); public static void HasCount<T>(int expected, Memory<T> memory);

   Span/ReadOnlySpan are ref structs so they cannot satisfy a generic IEnumerable<T> constraint — they need explicit overloads. Memory<T> could technically go through .ToArray() but a direct overload avoids the allocation.

2. Extend MSTEST0037 to flag Assert.AreEqual(x, span.Length) / Assert.AreEqual(x, memory.Length) and suggest Assert.HasCount(x, span) / Assert.HasCount(x, memory) once the overloads exist.

Naming consideration

HasCount reads slightly awkward for Span (.Length, not .Count). HasLength would fit better semantically, but I think API consistency wins — having one assertion name for "this sequence-like thing has N elements" is more discoverable than splitting by underlying property name. Happy to discuss.

Trade-offs

• Surface area grows by 4 overloads × interpolated-string variants. Cost is small and the family precedent (Assert.AreSequenceEqual already accepts ReadOnlySpan<T>) supports it.
• ref struct parameters mean these can't live behind a single generic, but they don't need to — explicit overloads are the standard pattern.

Related

• Assert.AreSequenceEqual already has ReadOnlySpan<T> overloads, so there's a precedent for span-aware assertion APIs.
• Found while reviewing Set MSTest.Sdk-wide defaults: UseMSTestSdk, method-level parallelization, Recommended analyzers dotnet/sdk#54766 — happy to send a PR if the proposal is accepted.

[avivanoff]

Still broken when targeting .NET Framework 4.8, etc.: MSTEST0037 is triggered, but Assert.HasCount overload does not exist.

[Evangelink]

Still broken when targeting .NET Framework 4.8, etc.: MSTEST0037 is triggered, but Assert.HasCount overload does not exist.

avivanoff Span and related APIs are not part of default netfx (they are available only when adding System.Memory NuGet package so we cannot add these APIs for netfx without forcing a new deps on the framework.

Also when you say it's broken, do you mean the analyzer triggers or doesn't trigger? On my repro project, I don't see the analyzer triggering so overall there is no "broken" experience there.

[avivanoff]

Amaury Levé (@Evangelink), never mind, it was a multi-target project, so I ended up with a bunch of #if NET8_0_OR_GREATER.

One more thing I noticed is that you do not trigger a warning on comparing the empty spans. For instance,

Assert.HasCount(0, span.Length);

should trigger a warning with a suggested resolution

Assert.IsEmpty(span);