fix: expand nested And/Or expectations in failure messages (#5573)

[thomhurst]

Summary

• Fix [Bug]: Chaining .And produces unclear Failure messages #5573: chaining 3+ .And / .Or produced confusing Expected both conditions and to be X messages because the nested combinator returned a placeholder (both conditions / either condition) when its enclosing combinator asked for its expectation.
• Override GetExpectation() on AndAssertion / OrAssertion to return the combined expansion, so nested chains flatten into a readable multi-line expectation.
• Indent continuation lines with a tab so chained clauses are visually grouped under the leading Expected.

Before

Expected both conditions
and to be in ascending order
but item at index 4 (1) was less than previous item (4)

After

Expected to have count equal to 5
	and to contain 3
	and to be in ascending order
but item at index 4 (1) was less than previous item (4)

Test plan

• New Three_Way_And_Chain_Error_Message_Expands_All_Expectations reproduces the issue and now passes.
• New Four_Way_And_Chain_Error_Message_Expands_All_Expectations covers deeper nesting.
• Existing BecauseTests, Throws.ExactlyTests, and AssertMultipleTests updated to match the new tab-indented format.
• Full TUnit.Assertions.Tests suite: 1974/1974 passing.

[claude]

Code Review

The fix is clean, minimal, and solves the root cause correctly. Here's my analysis:

What the fix does

The previous GetExpectation() on AndAssertion/OrAssertion returned a dead-end placeholder string ("both conditions" / "either condition"). When a parent combinator called GetExpectation() on a nested one, it got that placeholder instead of the real sub-chain expansion. The fix delegates GetExpectation() to BuildCombinedExpectation(), which recursively expands the full chain by calling InternalGetExpectation() on its children — causing the correct flattening at any depth.

Strengths

• Minimal footprint: Two one-line changes in the core logic cover the fix entirely.
• Self-healing recursion: Because BuildCombinedExpectation() delegates to _first.InternalGetExpectation(), which itself calls GetExpectation() on any nested combinator, an arbitrarily deep chain automatically flattens without any loop or explicit traversal.
• Good test coverage: The new tests verify both 3-way and 4-way chains, and the DoesNotContain("both conditions") assertion directly guards the regression.

Minor observation: O(N²) string work for deep chains

Each level of nesting calls BuildCombinedExpectation(), which re-expands all children via InternalGetExpectation(). For a chain of depth N, this is O(N²) string allocations. For realistic assertion chains (2–10 links) this is completely negligible — just worth knowing if someone ever chains 1000 assertions together and wonders why the failure message is slow to build.

Style note: tab vs. space for indentation

Using \t is a reasonable choice and produces clean visual grouping. One thing to watch: if downstream consumers parse or trim failure messages, a literal tab character can be surprising. Existing tests have already been updated to match the new format, which is the right approach.

Verdict

Overall this is a well-scoped, correct fix with good test coverage. No changes needed. Approving.

[claude]

Clean, minimal, correct fix. The recursive delegation from GetExpectation() to BuildCombinedExpectation() elegantly solves the root cause at any chain depth. Tests are well-targeted. Approving.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}