Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anonymous type BeEquivalentTo behaviour #49

Open
uokitomer opened this issue Oct 8, 2020 · 3 comments
Open

Anonymous type BeEquivalentTo behaviour #49

uokitomer opened this issue Oct 8, 2020 · 3 comments

Comments

@uokitomer
Copy link

uokitomer commented Oct 8, 2020

Hey guys, I noticed a weird behavior today using BeEquivalentTo, would you let me know if this is expected or if there is a work around:

I am using version 5.10.3

I have a class with the following set of properties

`public class ContactCreatedEvent()
{
public Guid ContactId { get; }

    public Guid PracticeId { get; } = Guid.NewGuid();

}`

I am asserting that my event should be equivalent to my expected event this way

contactCreatedEvent.Should().BeEquivalentTo(expectedEvent);

Where expected event is

var expectedEvent = new { ContactId = testContact.ContactId, };

As you can see expectedEvent is an anonymous type. If PracticeId is missing the assertion still pass.

I would expect that if there is a missing member in any of the two objects being compared the assertion should fail. I don't have too much experience using the library, I am not sure how the assertion works but I read the description of the method saying if any of the two objects have mismatch amount of properties the assertion should not pass, so I figured this might not be the desired behavior.

If I do the opposite (remove PracticeId from the ContactCreatedEvent and add it to the anonymous type) the assertion fails.

I am using anonymous type because this object actually has a lot of collection properties where I would like to exclude id fields given I don't care if they match but unfortunately I read here fluentassertions/fluentassertions#500 that there is no easy way to exclude all members of a collection from an assertion

Thank you!

@dennisdoomen
Copy link
Member

Thank you for contacting us. The behavior you're seeing is by design. If your expectation has only a single property, then FA will only validate that your subject has the same property with the same (equivalent) value. This was a big change in 5.0.0.

But I do see the XML comments are a bit misleading. We'll update those.

@dennisdoomen
Copy link
Member

Wait, why did you post this on the JSON version of FluentAssertions?

@uokitomer
Copy link
Author

My bad! is definitely not a JSON comparison what I am doing, I think I was watching the project for something else and ended up posting my issue here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants