[Feature request] EquivalentTo that compares similar objects of different types

[killergege]

Hello,

I'd like to have an overload on EquivalentTo (or a new constraint) that takes an object and will compare it with another object using reflection, which allows you to compare 2 similar objects of different types.
The constraint would check each public property of the target and source objects, using reflection, and will try to find the same property on the other object.
If they are of the same type, or a native type, it uses Equals, if the types are different, it also applies the EquivalentTo constraint.
If the property is a collection, it would apply EquivalentTo to each value of the collection, keeping the order.
The constraint fails if the property don't exist on the other object, or if the Equals returns false.

It would be even better if we could add options (like IgnoreCase for strings) to ignore some specified properties.

We need it a lot as we have entities for each layer of the application, but the objects are often very similar (if not identical) and it is a pain to maintain a comparison of each field, and for each sub-object.

Today most of the answers point to FluentAssertions, which provide BeEquivalentTo() but we don't like the fluent syntax for assertions and prefer NUnit's contraint syntax, and we feel that it does pretty much the same thing as NUnit constraint system so it would be redundant.
So we would reference that library only for that feature and would use the fluent syntax only for that instruction. Not great.

Is it something that has already been discussed (couldn't find anything), and would already have been rejected maybe ?

[stevenaw]

It sounds like you're trying to compare the "shapes" of two different objects. I haven't found a historical issue where this has been discussed. I'm hesitant myself as I feel there may be a lot of edge cases here but I'd be curious to see what @nunit/framework-team thinks?

A few edge cases I'd be concerned about handling correctly in a generalized implementation

• is a shape a superset or exact match
• does property order matter (likely not for equivalency, but would shape equivalency support also require the expectation to support exact shape matching?)
• is a shape comparison shallow or deep (would it extend to compare shapes of child objects)
  • Similar, would an array's shape require recursively checking all containing elements, homogenous or not
• nunit convenience type conversions would likely have to apply. how about tolerance?

@killergege In the absence of built-in support, one option you could try outside of using a third-party assertion library could be to convert your types into an intermediate representation like a JSON object and compare the resulting types (like in #3949).
If you're adventurous enough you could also try to write your own custom comparer too. One approach to this might be to convert each object into a Dictionary<string, object> map of property names + values and then doing an equivalency comparison on those.

[killergege]

Indeed, I expect this to be a feature quite hard to implement, especially if expected to handle all edge cases :).
I thought about JSON objects but it might be a little to strict. I'll take a look though.

As a workaround, I created my own constraint that encapsulates the package KellermanSoftware.CompareNetObjects which seem to be working so far, but we don't have a lot of strange cases in our code.
Few things I had to take into account:

• Some source objects have a lot more fields that target, so my constraint has a "direction" (it checks that the fields of one object exist and have the same value as the other, but does not a full comparison of both objects)
• Enums need a special handling. But our case is simple : we never care about the numeric value, so we make sure to cast them to string before comparing them.
• there's a few methods to add options to ignore some fields, and to check only the first level (by default it is recursive)
• The "difference" output is not the easiest to read though.

We are still testing it, we use it on objects that are really similar (which is like 90% of them), and all special cases are still compared manually.
So far, it works for us :)

[stevenaw]

@manfred-brands @OsirisTerje

I feel like the property comparer in NUnit 4 gets us part of the way to supporting this. It's currently awaiting feedback from the team as an idea.

Should we accept this as an enhancement? Are there any caveats or edge cases we'd focus on or choose not to support (ex: DTO only, property vs field, nested objects, etc). If we do add this to the framework, would it have a new API/constraint?

If accepted, my instinct on the API question is "yes, new API" as the shape-based check feels like a new concept in the framework. I would also suggest that if nested objects are supported that we add cycle detection up front to be consistent with how the IEnumerable comparer handles cyclical graphs.

Thoughts?

[manfred-brands]

@stevenaw It is more than the PropertiesComparer and do we want SuperSetOf and SubSetOf properties.

I liked your:

One approach to this might be to convert each object into a Dictionary<string, object> map of property names + values and then doing an equivalency comparison on those.

That allows checking that if one has all/some/more of the properties than the other and for those where the instances have the same properties, we can check values.

[SeanKilleen]

@manfred-brands My gut feeling: I believe NUnit should provide the basic assertions out of the box, but I'm comfortable deferring to libraries like FluentAssertions when this sort of ask is raised, because there are fully featured libraries that aren't huge dependencies and that allow users to quickly get to the outcome they want. I think our limited time might be best spent on other framework improvements and directing users to those tools.

I'm also fully open to understanding if there's a reason why that may not be an option, but I'm having trouble thinking of one now.

[manfred-brands]

@SeanKilleen You are right. As there already seems to be an extension nuget package doing what the reporter wants, we should probably close this issues.

[stevenaw]

Thanks for your feedbacks @manfred-brands @SeanKilleen
I'll close the issue

[OsirisTerje]

@stevenaw @manfred-brands I think we should reopen this, now that this actually is being fixed in #4925 . Are there anything in here that is not implemented in that PR ?