Nested AssertionScopes do not print inner scope reportables

Description

Nested AssertionScopes only report the outer-most scope reportables on failure. This is true regardless of whether the outer scope has any reportables – i.e., if only the inner scope has reportables, nothing is reported.

Complete minimal example reproducing the issue

[TestMethod]
public void TestNestedAssertionScopes()
{
    using (var outerScope = new AssertionScope())
    {
        outerScope.AddReportable("outerReportable", "foo"); // no behavior change if this is omitted
        // in my real use case, the inner scope is in a for loop with changing innerScope reportable values, so I can't use a single scope; 
        // the outer scope is used to ensure that a failure of one loop item continues running the rest of the loop
        using (var innerScope = new AssertionScope()) 
        {
            innerScope.AddReportable("innerReportable", "bar");

            int testVal = 2;
            testVal.Should().Be(1);
        }
    }
}

Expected behavior:

Message: Expected testVal to be 1, but found 2.

With outerReportable:
foo
With innerReportable:
bar

Actual behavior:

Message: Expected testVal to be 1, but found 2.

With outerReportable:
foo

Versions

• Which version of Fluent Assertions are you using? 6.5.1
• Which .NET runtime and version are you targeting? E.g. .NET framework 4.6.1 or .NET Core 2.1. .NET Framework 4.7.2

Additional Information

using Microsoft.VisualStudio.TestTools.UnitTesting test framework

[94sedighi]

Me and my friend Ruijin92 are two new Contributors working together on Issues and having our first experience in an open source project. We already have a solution for this bug and would be happy if you assign this “good first issue” to me or Ruijin92.

[dennisdoomen]

I think the most straightforward approach would be to have the inner scope yield its reportables to the “parent” when disposed, as is done with failure messages. There is a potential conflict here if inner and outer scopes attempt to use the same key though, as well as a few other cases - only the final value for a given key would be reported. I’m note entirely sure what the most appropriate behaviour should be.

I think that’s an acceptable solution. We just need to make sure that Discard also discard the reportables.