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

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);

1. 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 #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]

Updated the release motes.

[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.