ShouldBeEquivalentTo ignores differences in deserialized objects

[ccarmannt]

Description

When comparing objects deserialized from JSON strings, differences are ignored.

Complete minimal example reproducing the issue

Example 1:

var a = JsonConvert.DeserializeObject("{\"x\": 8}");
var b = JsonConvert.DeserializeObject("{\"x\": 7}");
a.Should().BeEquivalentTo(b);

Example 2:

var a = JsonConvert.DeserializeObject<JObject>("{\"x\": 8}");
var b = JsonConvert.DeserializeObject<JObject>("{\"x\": 7}");
a.Should().BeEquivalentTo(b);

Expected behavior:

In both of these examples, the two objects should be flagged as NOT equivalent.

Actual behavior:

The two objects are claimed to be equivalent.

Versions

• Which version of Fluent Assertions are you using?
• • 5.10.3
• • (also tried 6.3.0)
• 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

Any additional information, configuration or data that might be necessary to reproduce the issue.

[dennisdoomen]

That's because you're comparing two instances of type object, which doesn't define any compile-time properties. But even if you would use the options to force FA to respect the runtime types, the behavior is difficult to predict. JSonConvert returns a complicated graph of JContainer instances. Instead, I recommend using FluentAssertion.Json. It also has a BeEquivalentTo method that was specifically designed to work with Json objects. Just make sure you use using FluentAssertions.Json.

[ccarmannt]

Thanks for the quick resolution.

Are there any other class types that can't be handled, and should there be a caveat in the documentation about these?

[dennisdoomen]

It's not that it doesn't support it. It's just that these types of objects have a complicated object graph structure with lots of members and cyclic references, and are not intended to be compared in such a way. So FA will still try to compare them by their members (depending or not if the objects in the graph override Equals or not), but it's not to give you anything that you can use. Hence the need for a separate package that uses NewtownSoft.Json native capabilities to traverse the JSon structure.

[ccarmannt]

Cool, thanks.