I am running XUnit tests using AngleSharp for HTML inspection and FluentAssertions for assertions. It turns out that when an assertion fails on a IElement object, the test run ends up spinning for such a long time, hugging up a CPU core.

Complete minimal example reproducing the issue

The following code depends on AngleSharp.

// Arrange
var someMarkup = @"<p id=""paragraph"">This is an element</p>";

var parser = new AngleSharp.Html.Parser.HtmlParser();
var document = parser.ParseDocument(someMarkup);

// Act
IElement element = document.QuerySelector("#paragraph");

// Assert
element.Should().BeNull(); // at this point element is not null, and the assertion should fail

Expected behavior:

My test should fail, since element is null. Using the non-null primitive, I don't require to have a complete description of my non-null object.

Actual behavior:

It takes so much time formatting the string for the IElement object that the tests ends up timeout. If I am running under Visual Studio, Visual Studio will just become non responsive for more than five minutes (I didn't try to let it run further)

Versions

FluentAssertions 5.6.0
.NET Core 2.2.0
AngleSharp 0.11.0

Additional Information

When you look at the structure of the IElement object, you can see that it was structure with a lot of HTML navigation concepts, such as (Child, NextSibling, Parent). The graph has no leaf.

The current implementation of cyclic reference detection works well, but the possible combination/permutation of properties within this class is making the Formatter needlessly trying to get all the properties through different navigational properties.

Wouldn't there be a reasonable limit to how much formatting should dig properties ? At some point, having +100 properties display seems (to me) plainly too much. In this case I've printed more than 12000 and estimated that I am not even at 8% of what I could have print...