fluentassertions: `Should().BeEquivalentTo()` show different error message between Debug and Release
Description
We compile and launch unit test libraries with the release configuration and x64 platform.
After upgrading FluentAssertions from 4.19.2 to 6.5.1 (the latest), we noticed that Should().BeEquivalentTo() gives different error messages while compare classes with properties.
Let’s look at the following example:
- Let
ClassWithPropertybe a class containing one propertyIntProperty:
public sealed class ClassWithProperty
{
public ClassWithProperty(int value)
{
IntProperty = value;
}
public int IntProperty { get; }
}
- The unit test
CompareClassWithPropertyObjectscompare two objects of typeClassWithProperty, with different property values.
[Test]
public void CompareClassWithPropertyObjects()
{
//Arrange
var actual = new ClassWithProperty(1);
var expected = new ClassWithProperty(2);
//Assert
actual.Should().BeEquivalentTo(expected);
}
Expected behavior:
Expected property actual.IntProperty to be 2, but found 1.
With configuration:
- Use declared types and members
- Compare enums by value
- Compare tuples by their properties
- Compare anonymous types by their properties
- Compare records by their members
- Match member by name (or throw)
- Be strict about the order of items in byte arrays
- Without automatic conversion.
Actual behavior:
Here, it outputs the }}}, instead of the name of the actual object.
Expected property }}}.IntProperty to be 2, but found 1.
With configuration:
- Use declared types and members
- Compare enums by value
- Compare tuples by their properties
- Compare anonymous types by their properties
- Compare records by their members
- Match member by name (or throw)
- Be strict about the order of items in byte arrays
- Without automatic conversion.
Versions
- .NET :
.NET Core 3.1and.NET 4.7.1 - NUnit :
3.12.0(I tried also the the version3.13.1, It gives the same results). - FluentAssertions :
6.5.1 - Configuration :
Release - Platform :
x64
Note that it works totally fine in Debug configuration.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 16 (16 by maintainers)
I’ve just tried your example, but it works on my Windows machine
Either way, this seems to be unrelated to the original issue. So please create a separate issue so to not obfuscate the original issue.
I did a related analysis in https://github.com/fluentassertions/fluentassertions/issues/1781#issuecomment-1016784748
As is documented here, you need to run your tests in Debug mode for FA to be able to extract the variable from the stack trace. Otherwise the compiler will optimize those details away. However, it should fall back to using a generic name, so technically it’s a little bug.