Allow inclusion of (caller argument) expression information in failure messages to be disabled

[drieseng]

Summary

I'd like to have a way to disable inclusion of (caller argument) expression information in failure messages.

Background and Motivation

I'm sure the inclusion of (caller argument) expression information in failure messages is greatly appreciated by a wide audience, but - personally - I don't see much value in it.

I would greatly appreciate a means to disable it (via runsettings?).

Having failure messages such as Assert.IsNull failed. 'value' expression: 'actual'. do not provide useful information (to me!). As long as you have an accurate stack trace, you have enough to investigate the test failure.

[Evangelink]

RFC 011 — Structured Assertion Messages redesigns how assertion failure messages are structured, and this should largely address the concern here.

Today, the caller expression info is displayed inline as part of the failure message itself, which makes it feel noisy:

Assert.IsNull failed. 'value' expression: 'actual'.

With the RFC, the expression is no longer rendered as 'param' expression: 'expr' fragments mixed into the message. Instead, it's displayed as a reconstructed call-site at the very bottom, right before the stack trace — where you'd naturally look for location info:

Assertion failed. Expected value to be null.

actual: "some value"

Assert.IsNull(actual)
   at MyTests.Foo.IsNull() in Foo.cs:line 10

This reads as a natural extension of the stack trace rather than noise in the failure description. The important information (what failed, what the value was) comes first, and the call-site is supplementary context at the end.

We'll revisit whether a dedicated opt-out setting is needed once the new format ships — but we believe the structural redesign itself should make the expression info much less bothersome.

[drieseng]

Great, looking forward to that. Feel free to close this issue.

[Evangelink]

I'll keep it open for now in case the RFC + implementation drifts.