Improve assertions error messages with structured format

[Evangelink]

Fix #7421

[Copilot]

Pull request overview

This pull request modernizes assertion error messages by introducing a structured, multi-line format that improves readability and developer experience. The changes replace old-style concatenated messages with formatted parameter displays using raw string literals.

Changes:

• Introduced structured error message formatting with parameter names, expressions, and values on separate lines
• Added helper methods for value formatting, expression truncation, and redundancy detection
• Updated all assertion methods to use the new formatting approach
• Removed obsolete resource strings and added new simplified ones
• Updated all test expectations to match the new message format

Reviewed changes

Copilot reviewed 41 out of 41 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
Assert.cs	Core formatting infrastructure: FormatValue, FormatParameter, truncation logic
Assert.ThrowsException.cs	Updated to new structured format for exception type mismatches
Assert.StartsWith/EndsWith/Matches.cs	String assertion methods using new format
Assert.IsTrue/IsFalse.cs	Boolean assertion methods with condition parameter display
Assert.IsNull/IsNotNull.cs	Null checking assertions with value display
Assert.IsInstanceOfType/IsExactInstanceOfType.cs	Type checking with structured type comparison
Assert.IComparable.cs	Comparison assertions (greater/less than, positive/negative)
Assert.Count/Contains.cs	Collection assertions with expression parameters
Assert.AreSame.cs	Reference equality with hash code display for disambiguation
FrameworkMessages.resx	Resource string simplification and new message keys
xlf files	Localization files marked with untranslated entries
Test files	Updated expectations for all assertion error messages

[Copilot]

Pull request overview

Copilot reviewed 44 out of 44 changed files in this pull request and generated 7 comments.

[Copilot]

Pull request overview

Copilot reviewed 44 out of 44 changed files in this pull request and generated no new comments.

[nohwnd]

looks great

[Copilot]

Pull request overview

Copilot reviewed 46 out of 46 changed files in this pull request and generated 6 comments.

Comments suppressed due to low confidence (2)

src/TestFramework/TestFramework/Assertions/Assert.IsInstanceOfType.cs:343

• When expectedType is null (one of the documented failure cases), the failure message currently only prints the value line and omits any indication that expectedType was null. This makes the assertion failure hard to diagnose. Consider either validating expectedType with CheckParameterNotNull (like other asserts do) or including an explicit "expectedType: (null)" / reason line in the structured output.

        string message = string.IsNullOrEmpty(userMessage) ? string.Empty : userMessage!;
        if (expectedType is not null && value is not null)
        {
            message += Environment.NewLine + FrameworkMessages.IsInstanceOfTypeFailNew;
        }

        message += Environment.NewLine + FormatParameter(nameof(value), valueExpression, value);
        if (expectedType is not null && value is not null)
        {
            message += Environment.NewLine + $"  expectedType: {expectedType}"
                     + Environment.NewLine + $"  actualType: {value.GetType()}";
        }

src/TestFramework/TestFramework/Assertions/Assert.IsExactInstanceOfType.cs:336

• When expectedType is null, IsExactInstanceOfType fails but the structured message doesn't indicate that expectedType was null (it only prints the value line). Consider validating expectedType with CheckParameterNotNull or adding an explicit "expectedType: (null)" / reason line so callers can understand why the assert failed.

    private static void ThrowAssertIsExactInstanceOfTypeFailed(object? value, Type? expectedType, string? userMessage, string valueExpression)
    {
        string message = string.IsNullOrEmpty(userMessage) ? string.Empty : userMessage!;
        if (expectedType is not null && value is not null)
        {
            message += Environment.NewLine + FrameworkMessages.IsExactInstanceOfTypeFailNew;
        }

        message += Environment.NewLine + FormatParameter(nameof(value), valueExpression, value);
        if (expectedType is not null && value is not null)
        {
            message += Environment.NewLine + $"  expectedType: {expectedType}"
                     + Environment.NewLine + $"  actualType: {value.GetType()}";
        }

[Copilot]

When wrongType is null, IsNotExactInstanceOfType fails but the structured message omits any mention that wrongType was null. Since wrongType being null is a primary cause, consider validating wrongType with CheckParameterNotNull or including a "wrongType: (null)" / reason line in the message.

This issue also appears on line 323 of the same file.

Suggested change

	}
	}
	else
	{
	message += Environment.NewLine + " wrongType: (null)"
	+ Environment.NewLine + " reason: The parameter 'wrongType' must not be null.";
	}

[Evangelink]

Fixed. When wrongType is null, the message now always includes the failure message and shows wrongType: (null) as a diagnostic. Also applied the same fix to ThrowAssertIsExactInstanceOfTypeFailed (line 323) to handle expectedType being null. Updated tests accordingly.

[Copilot]

ThrowAssertFailed special-cases messages that start with a newline by constructing the prefix with a hardcoded English string ("{assertionName} failed."). This bypasses the localized FrameworkMessages.AssertionFailed format and will regress non-English assertion prefixes whenever structured messages start with a newline. Consider keeping the localization by deriving the prefix from FrameworkMessages.AssertionFailed (e.g., formatting with an empty message and trimming trailing whitespace) rather than hardcoding "failed.".

Suggested change

	// the format produces a trailing space before the newline ("failed. \\r\\n").
	// Remove it to avoid trailing whitespace on the first line.
	if (message is not null && message.StartsWith(Environment.NewLine, StringComparison.Ordinal))
	{
	formattedMessage = $"{assertionName} failed.{message}";
	// the format produces a trailing space before the newline (for example, "failed. \\r\\n").
	// Remove it to avoid trailing whitespace on the first line while preserving localization.
	if (message is not null && message.StartsWith(Environment.NewLine, StringComparison.Ordinal))
	{
	string prefix = string.Format(CultureInfo.CurrentCulture, FrameworkMessages.AssertionFailed, assertionName, string.Empty);
	formattedMessage = prefix.TrimEnd() + message;

[Copilot]

Per repo localization guidelines, *.xlf files shouldn't be edited manually. These XLF changes should be produced by updating the .resx and then building to regenerate the XLFs. Please revert any hand edits and regenerate the XLF file(s) from the build pipeline to avoid translation merge issues.

Suggested change

	<note />
	<note></note>

[Evangelink]

The XLF files were regenerated by building the project (dotnet build). The format is now whatever the build tooling produces.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.