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

BeEquivalentTo shows enums as decimal in error message #897

Closed
robvanuden opened this issue Aug 17, 2018 · 5 comments
Closed

BeEquivalentTo shows enums as decimal in error message #897

robvanuden opened this issue Aug 17, 2018 · 5 comments

Comments

@robvanuden
Copy link
Contributor

Description

BeEquivalentTo shows enums as decimal in error message

public enum Color
{
    Red,Blue
}

Expected member Color to be 1M, but found 0M.

Complete minimal example reproducing the issue

public enum Color
{
    Red,Blue
}

public class Car
{
    public Color Color { get; set; }
}

[Fact]
public void Test()
{
    var car = new Car
    {
        Color = Color.Red
    };
    car.Should().BeEquivalentTo(new Car() { Color = Color.Blue });
}

Expected behavior:

Message: Expected member Color to be Blue, but found Red.

Actual behavior:

Message: Expected member Color to be 1M, but found 0M.

Versions

  • FluentAssertions 5.4.1
  • .NET Core 2.0

Additional Information

Running in Xunit, when relevant.

@jnyrup
Copy link
Member

jnyrup commented Aug 18, 2018

Thanks for bringing this up.

The default behavior for comparing enums in BeEquivalentTo is to compare them by value.
That is, two (different) enums are considered equivalent if and only if their underlying values are equal.

If you want to compare the enums by name instead, you can use

car.Should().BeEquivalentTo(new Car() { Color = Color.Blue },
    opt => opt.ComparingEnumsByName());

which changes the failure message to

Message: Expected member Color to be "Blue" with a length of 4, but "Red" has a length of 3.

With configuration:
- Use declared types and members
- Compare enums by name
- Match member by name (or throw)
- Without automatic conversion.
- Be strict about the order of items in byte arrays

Getting back to your issue, I think the failure message can be improved for both ComparingEnumsByName and ComparingEnumsByValue.

Some ideas for the failure message:

  • Expected member Color to be Color.Blue, but found Color.Red.
  • Expected member Color to be Blue (1), but found Red (0).
  • Expected member Color to be Color.Blue (1), but found Color.Red (0).

Including more details is useful if one e.g. compares Color.Red = 0 with AnotherColor.Red = 1 by value.
Only displaying Message: Expected member Color to be Blue, but found Red. would be confusing.

The relevant class is EnumEqualityStep.

@robvanuden
Copy link
Contributor Author

Didn't know about opt => opt.ComparingEnumsByName(), but what you're saying all makes sense. Thanks for the information.

@krajek
Copy link
Contributor

krajek commented Sep 28, 2018

@dennisdoomen can we close this one?

@dennisdoomen
Copy link
Member

If @robvanuden agrees, then yes?

@robvanuden
Copy link
Contributor Author

Agree, thanks @krajek!

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

4 participants