[Feature]: Make assertions with 'because' parameter more friendly to F#

[cmeeren]

Background and motivation

I love FluentAssertions and use it for F#. However, F#'s overload resolution is different than that of C#. One effect is that all overloads with because and becauseArgs require specifying because. For example,

result.Should().BeNull()

will not compile. Instead, it is required to write

result.Should().BeNull("")

This makes all assertions in F# more noisy. This is particularly noticeable for assertions that use a lambda parameter before because, since then the lambda is not the last argument and it then requires extra parentheses.

I suggest adding overloads for all assertions that do not have because or becauseArgs. That will allow F# users to assert without having to specify empty strings everywhere.

While I cannot promise anything, I may be willing and able to do a one-time pass of the codebase and add these overloads (at least as long as you don't see the need for separate tests and the overloads can just call existing overloads with an empty string argument). I can not prioritize adding and maintaining such overloads for all future assertions, but the additional work involved is trivial when new assertions are added.

Alternative Concerns

No response

[cmeeren]

at least as long as you don't see the need for separate tests

Actually, a (compile-only) F# test project with code that calls these overloads, just to ensure it compiles (which is the issue here), seems like a good idea. I would be willing to add that.

[jnyrup]

Did you see #1528?

[cmeeren]

I did not, thank you for the link.

For reference, as I understand it, what's causing trouble for F# is specifically optional parameters followed by a params array. It can handle either of them on its own just fine, but when combined, the optional parameters become required. I asked for F# to support this in fsharp/fslang-suggestions#1267, but based on what I can surmise from the comments there, I don't have high hopes of this ever being supported.

Adding the overloads I ask for would indeed double the API surface, though it would consist of only trivial overloads. But if you previously had and then removed those overloads when default parameter values got supported in C#, I can understand you don't want to re-add them. Just know that the cost is more pain when used from F#.

Feel free to close if you think this has been irrevocably decided against. If not, I'm happy to continue discussion.

[dennisdoomen]

We understand your problem, but from this project's perspective the costs do not outweigh the benefits. Maintaining a library like Fluent Assertions is already taking a big chunk of our free time.

[dennisdoomen]

While thinking about this, one way the F# community could support this is to build another C# class library that adds the necessary overloads as extension methods to e.g. CollectionAssertions classes in FluentAssertions. This could become a separate community-supported NuGet package.

[jnyrup]

Good idea to make a new library to improve the usage the usage for F# users 👍
It could even be an F# library with a name like FluentAssertions.FSharp or FluentAssertions.FSharpPolyfills.

[cmeeren]

I have looked into this, and I don't believe it can be easily done with the current design of FluentAssertions. I am therefore in the process of making a brand new F# assertions library combining the best of FluentAssertions and Shouldly (in particular, I find Shouldly's message format more readable). The library is not done or published yet, but is WIP here: cmeeren/Faqt. Hoping to have a feature complete version published within a month.

[dennisdoomen]

I have looked into this, and I don't believe it can be easily done with the current design of FluentAssertions. I am therefore in the process of making a brand new F# assertions library combining the best of FluentAssertions and Shouldly (in particular, I find Shouldly's message format more readable). The library is not done or published yet, but is WIP here: cmeeren/Faqt. Hoping to have a feature complete version published within a month.

Cool! I'll keep an eye on that. For what it's worth, you could name it FluentAssertions.FSharp and become part of the FluentAssertions organization. It may help with your marketing.

[cmeeren]

Thanks for the offer!

I find that FluentAssertions.FSharp makes it sound like an add-on to FluentAssertions, which it's not. Indeed, in focusing towards F# users and their expectations and idioms, the library will actively take a step away from FluentAssertions in some respects (dropping/adding/changing functionality). Therefore, I'm leaning toward sticking with the current name, "Faqt". In any case, my main motivation for OSS projects has never been getting the most users (though I of course want people who want/need it to know about it). Furthermore, if I get it posted on F# Weekly (which is just a tweet away), then I think that will be all the focused marketing I need.

FluentAssertions is however welcome to point F# users to Faqt! 🙂