[Feature Request] PropertiesComparer for different types

[Edgaras91]

Please add support for comparing 2 different object types, that have the same (or different) properties, to compare their property values.
Very similar to
Assert.That(one, Is.EqualTo(two).UsingPropertiesComparer());
but for different types. Then a parameter to map different properties, or ignore different properties.

A direct replacement for FluentAssertions customerEntity.Should().BeEquivalentTo(customerDto) in hopes of uninstalling that package due to a recent license change.

Edit: I realised this is a duplicate of: #4244

[manfred-brands]

comparing 2 different object types, that have the same (or different) properties

I can accept same to compare Dto and Db classes as long as they are 1:1.

Then a parameter to map different properties

Not sure what syntax you had in mind that is type safe and not involves strings.

It would probably be clearer and simpler if you compare the individual properties directly:

Assert.That(one.PropertyA, Is.EqualTo(two.Property1));

[killergege]

Yes, this is a duplicate of the issue I raised years ago, but the situation has changed since.
Conclusion on the issue was that FluentAssertion is doing the job so it's not necessary to do it in NUnit. Now that they decided to licence the library at stupid prices, it's not the same, I hope the NUnit team would reconsider.

@manfred-brands It not really clearer and simpler when you have deep objects and a lot of fields.
It makes the tests cluttered by very repetitive assertions, masking the important part of the tests, and you can easily forget to add a new field.

In our api we have a lot of those, as we have internal types & exposed types (mapped with AutoMapper) that are usually very similar except a few ignored or transformed fields.
.Should().BeEquivalentTo() was a very good solution with a lot of options (this is the only reason we used FluentAssertion, we prefer the Assert.That() pattern over the .Should()).
Even with less flexibility (at least supporting 1:1 objects would be great), it would be nice to have a similar feature in NUnit.

Few years ago, I started to work on a custom constraint using Compare-Net-Objects as its core comparer, but it has too many bugs, and is not maintained anymore.
Also, sadly NUnit does not seem to use generic constraints so I had to "manually" specify the types, which was not great.
We then decided to use FluentAssertion...

[manfred-brands]

@Edgaras91 @killergege I would like a few clarifications:

• What do you expect the result to be if actual has more/less properties than expected?
  • Fail
  • Only compare the common properties, ignoring the others?
  • Depending on OnlyCompareCommonProperties flag.

I have added the following to #4925:

Assert.That(usPerson, Is.EqualTo(person).UsingPropertiesComparer(
    c => c.Map<USPerson>(x => x.Address, y => y.USAddress)
            .Map<Address, USAddress>(x => x.AreaCode, y => y.ZipCode)
            .Map<Address>(x => x.Country, "U.S.A.")));

If there is a mismatch it will be reported like:

  Expected: <Person { Name = John Doe, Address = Address { House = 10, Street = CSI, City = Las Vegas, AreaCode = 89030, Country = U.S.A. } }>
  But was:  <USPerson { Name = John Doe, USAddress = USAddress { House = 10, Street = CSI, City = Las Vegas, ZipCode = 89031 } }>
  Values differ at property Person.Address => USPerson.USAddress:
  Expected: <Address { House = 10, Street = CSI, City = Las Vegas, AreaCode = 89030, Country = U.S.A. }>
  But was:  <USAddress { House = 10, Street = CSI, City = Las Vegas, ZipCode = 89031 }>
  Values differ at property Address.AreaCode => USAddress.ZipCode:
  String lengths are both 5. Strings differ at index 4.
  Expected: "89030"
  But was:  "89031"
  ---------------^

[killergege]

I guess depending on a flag would be best for most people.

But in our specific case, we prefer strict comparison so we would configure it to fail (set the flag to false).
In that situation it should be also possible to explicitely ignore a field from the comparison - FluentAssertion has a Excluding(x=>x.Field) extension method (I see that you planned something similar, awesome).

[Edgaras91]

Do we know when this will be released?
I updated NUnit to 4.3.2 (Released on Dec 28, 2024), but I still can't see the overload (as expected).
I also noticed you don't do prerelease packages.

[vvidetta-gearset]

Do we know when this will be released? I updated NUnit to 4.3.2 (Released on Dec 28, 2024), but I still can't see the overload (as expected). I also noticed you don't do prerelease packages.

Just wanted to +1 @Edgaras91's question. It would be really handy to have this, since it looks like .UsingPropertiesComparer gives more localised feedback on diffs. I have a test that uses EqualConstraint.Using at the moment. This is fine when the test passes, but when it fails it's quite hard to zone in on the exact members that differ, since the framework just logs a complete object dump. Moreover, some members (e.g. Lists) are opaque and just displayed as a reference.

The docs may have been updated prematurely, since they already reference version 4.4.

[mikkelbu]

@Edgaras91, @vvidetta-gearset You can find the prereleases on myget - https://www.myget.org/feed/nunit/package/nuget/NUnit.

When this will be released I cannot answer, there are no open items in the milestone - https://github.com/nunit/nunit/milestone/53 - but I think some people are traveling at the moment AFAICR.