Format records and anonymous types with their member values

[benagain]

#2140 - Enhance the output formatter so that record, anonymous types and tuples output are displayed as their member values rather than their ToString implementation.

Before:

Expected object to be <null> because classes without ToString output members, but found FluentAssertions.Specs.Formatting.FormatterSpecs+Stuff`1[[System.Int32, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]
{
    Children = {1, 2, 3, 4}, 
    Description = <null>, 
    StuffId = 1
}.
Expected object to be <null> because anonymous classes output members, but found { AnonymousClassId = 1, Children = System.Int32[] }.
Expected object to be <null> because records output members, but found StuffRecord { RecordId = 1, RecordDescription = description, RecordChildren = System.Collections.Generic.List`1[System.Int32] }.
Expected tuple to be <null> because tuples output members, but found (1, description, System.Collections.Generic.List`1[System.Int32]).

After:

Expected object to be <null> because classes without ToString output members, but found FluentAssertions.Specs.Formatting.FormatterSpecs+Stuff`1[[System.Int32, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]
{
    Children = {1, 2, 3, 4}, 
    Description = <null>, 
    StuffId = 1
}.
Expected object to be <null> because anonymous classes output members, but found {
    AnonymousClassId = 1, 
    Children = {1, 2, 3, 4}
}.
Expected object to be <null> because records output members, but found FluentAssertions.Specs.Formatting.FormatterSpecs+StuffRecord
{
    RecordChildren = {1, 2, 3, 4}, 
    RecordDescription = "description", 
    RecordId = 1, 
    SingleChild = 
    FluentAssertions.Specs.Formatting.FormatterSpecs+ChildRecord
    {
        ChildRecordId = 80
    }
}.
Expected tuple to be <null> because tuples output members, but found {
    Item1 = 1, 
    Item2 = "description", 
    Item3 = {1, 2, 3, 4}
}.

IMPORTANT

• If the PR touches the public API, the changes have been approved in a separate issue with the "api-approved" label.
• The code complies with the Coding Guidelines for C#.
• The changes are covered by unit tests which follow the Arrange-Act-Assert syntax and the naming conventions such as is used in these tests.
• If the PR adds a feature or fixes a bug, please update the release notes with a functional description that explains what the change means to consumers of this library, which are published on the website.
• If the PR changes the public API the changes needs to be included by running AcceptApiChanges.ps1 or AcceptApiChanges.sh.
• If the PR affects the documentation, please include your changes in this pull request so the documentation will appear on the website.
  • Please also run ./build.sh --target spellcheck or .\build.ps1 --target spellcheck before pushing and check the good outcome

[coveralls]

Pull Request Test Coverage Report for Build 4804953154

• 77 of 83 (92.77%) changed or added relevant lines in 6 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.03%) to 97.21%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
Src/FluentAssertions/Formatting/FormattedObjectGraph.cs	39	45	86.67%

Totals
Change from base Build 4777172174:	-0.03%
Covered Lines:	12897
Relevant Lines:	13139

---

💛 - Coveralls

[dennisdoomen]

🤔 Would be nice to have an example of the before and after situations in the PR description

[benagain]

Hi @dennisdoomen @lg2de, is there anything else to do for this PR?

[dennisdoomen]

Hi @dennisdoomen @lg2de, is there anything else to do for this PR?

No, waiting for @jnyrup to find some time to review the PR as well.

[jnyrup]

Great work.
I really liked reviewing this and how we gradually improved it one step a time.

[jnyrup]

@dennisdoomen Will you have another look since the implementation changed some since your approval.

[dennisdoomen]

❓Wouldn't it make the output better readable if we add an empty line after a multi-line "Expected..." statement? Just like we do in C#.

@benagain sorry for some of the new comments. But as @jnyrup requested, I had a bit of a more thorough look at the PR (and the output we used to generate). Very happy with the improvements. We just need to make sure it's picture perfect.

[benagain]

❓Wouldn't it make the output better readable if we add an empty line after a multi-line "Expected..." statement? Just like we do in C#.

I'm not entirely sure what you mean here @dennisdoomen, is this the same as #2144 (comment)? If not, could you elaborate a little please?

@benagain sorry for some of the new comments. But as @jnyrup requested, I had a bit of a more thorough look at the PR (and the output we used to generate). Very happy with the improvements. We just need to make sure it's picture perfect.

No problem, I'm quite enjoying polishing it to get it right.

[dennisdoomen]

I'm not entirely sure what you mean here @dennisdoomen, is this the same as #2144 (comment)? If not, could you elaborate a little please?

Yeah, I meant the same thing there.

[dennisdoomen]

@benagain I assume you're still working on this PR. Ping me when you're done and I can conclude the review.

[benagain]

@benagain I assume you're still working on this PR. Ping me when you're done and I can conclude the review.

Hi @dennisdoomen, I found an annoying problem that has been tricky to resolve. As it currently stands a list of objects will be formatted with the list's opening brace and the first object's name on the same line as "Expected...", rather than on a new line:

  Expected stuff to be equal to {FluentAssertions.Specs.Formatting.FormatterSpecs+Stuff`1[[System.Int32*]]
      {
          Children = {1, 2, 3, 4}, 
  ...

This comes down to the interplay between EnumerableValueFormatter and FormattedObjectGraph and is challenging because simple, short lists should be formatted on the original line:

Expected list to be equal to {1,2,3,4}

I'm fairly close to a solution but I will be the first to say it's a touch convoluted. Maybe when I show the code someone will have a better idea.

[benagain]

@dennisdoomen, @lg2de, @jnyrup, and anyone else interested!..

I'd like to draw your attention to the test When_the_object_is_a_generic_type_without_custom_string_representation_it_should_show_the_properties:

fluentassertions/Tests/FluentAssertions.Specs/Formatting/FormatterSpecs.cs

Lines 213 to 223 in 0d74c41

	act.Should().Throw<XunitException>()
	.And.Message.Should().Match(
	"""
	Expected stuff to be equal to
	{
	FluentAssertions.Specs.Formatting.FormatterSpecs+Stuff`1[[System.Int32*]]
	{
	Children = {1, 2, 3, 4},
	Description = "Stuff_1",
	StuffId = 1
	},

I think this formatting is what we're after, especially the newline after "expected stuff to be", and indentation of the type name to match the type contents.

This particular stuff is a list of complex objects, and the EnumerableFormatter does not know whether or not to put that opening brace on a newline until it has formatted at least one child. Lists of integers should be formatted on a single line:

Expected numbers to be {1, 2, 3, 4}

I tried a few different things, then came up with PossibleMultilineFragment formatter which tracks where the brace should go in the output, and then insert it later on after we know if this enumerable is single-line or spans multiple lines. EnumerableFormatter was already making a "single or multi-line" decision so I think this follow that pattern. Inserting content into the graph post-hoc required more access to the internals of FormattedObjectGraph so I felt it should be a responsibility of that now.

Please have a look. It seems a bit overly complicated for what should be something simple but I have not yet thought of a better solution whilst keeping the desired formatting.

[lg2de]

I like what I see in the new tests!

[benagain]

Hi @dennisdoomen, could you have another look at this please. I think I have covered all of the comments 🤞

[dennisdoomen]

Impressive work. This entire graph formatting has become pretty complicated, so kudos for you to grasp that complexity and improve on it.

[benagain]

Thanks everyone for the robust review! 😃