Hidden breaking change in 5.5.0: Assertions on Func lose access to ObjectAssertions

[adamgauthier]

Description

I came across this while bumping the version we use in our repository. Basically any code that used assertions from ObjectAssertions like .Should().Be() on Func<T> types won't compile when FluentAssertion is bumped to 5.5.0, because FuncAssertions was added and inherits from ReferenceTypeAssertions, but not from ObjectAssertions.

I think most if not all use cases for assertions on Func<T> are covered by ReferenceTypeAssertions, so Be can easily be swapped by BeSameAs. However, this sort of breaking change is unexpected and confusing.

Complete minimal example reproducing the issue

1. Reference FluentAssertions 5.4.2 and use a Should().Be() assertion on a Func<T> object.

<PackageReference Include="FluentAssertions" Version="5.4.2" />

Func<string> func = () => string.Empty;
var funcs = new[] { func };

var result = funcs[0];

result.Should().Be(func);

2. Bump reference to version 5.5.0.

Expected behavior:

The minor version bump is seamless and no breaking changes are encountered.

Actual behavior:

A compilation error is encountered:

Error CS1061 'FunctionAssertions<string>' does not contain a definition for 'Be' and no accessible extension method 'Be' accepting a first argument of type 'FunctionAssertions<string>' could be found (are you missing a using directive or an assembly reference?)

Additional Information

• Issue is present in all versions since 5.5.0, including 5.5.3 and latest 5.9.0.
• Release notes don't mention such a possible breaking change.
• Issue was introduced in Should().Throw and Should().NotThrow throw for Func<T> #951, where FunctionAssertions was added.
• Issue occurs for all assertions present in ObjectAssertions but not ReferenceTypeAssertions, namely Be, NotBe, BeEquivalentTo, HaveFlag and NotHaveFlag.
• Issue can be resolved by replacing usage of Be() by BeSameAs().

[dennisdoomen]

Thanks for reporting this and the elaborate issue description. Technically you're right. But I'm in doubt whether we should fix this. What kind of behavior would you expect when using Be on a Func<T>? Those things don't override Equals, so in principle I would recommend using BeSameAs to emphasize you're comparing references and not relying on equality.

BeEquivalentTo is already available on the specific assertion types for which this makes sense. HaveFlag and NotHaveFlag are only meant for enumerations.

[adamgauthier]

I agree, I feel like just amending the release notes to mention this is a good enough resolution for this issue.

[dennisdoomen]

Sure. How would you phrase it?

[adamgauthier]

I'm not sure, maybe an addition to the bottom note of 5.5.1 release notes like

"Since the addition of Should().Throw and Should().NotThrow for Func<T>, assertions Should().Be and Should().NotBe can't be used on Func<T> objects anymore, so this may cause breaking changes. These instances can easily be replaced with Should().BeSameAs and Should().NotBeSameAs as these types are compared by references."

[dennisdoomen]

Updated the release motes.