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.

[Evangelink]

Closing in line with the earlier comment thread: RFC 012 — Structured Assertion Messages restructures every failure message so that the caller-argument-expression info is no longer interleaved in the headline as 'value' expression: 'actual'. noise. Instead, the message reads top-down as:

Assertion failed. Expected value to be null.

actual: "some value"

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

The call-site expression now sits as a reconstructed line right above the stack trace — visually it is part of the location info rather than part of the failure description. Based on that we never added an explicit opt-out setting.

If the new format still feels noisy in a concrete scenario, please open a focused issue with the rendered message so we can tune that specific case rather than introducing a global toggle.