Improve test consistency by using only FluentAssertions

[sander1095]

Description
An example, though others can be found as well: https://github.com/meilisearch/meilisearch-dotnet/blob/main/tests/Meilisearch.Tests/IndexTests.cs#L167

This line allows the Limit property to be 1 or greater. As far as I know, the result will always be 1; the next line actually says that only 1 is the allowed outcome (This is duplicate code and I created #333 for this).

Basic example
So why do we use BeGreaterOrEqualTo(1)? In this case, we should be using Be(1).

I would suggest that we go through IndexesTests.cs at least, and clean up these kind of tests by narrowing down the accepted test results.

Other
Any other things you want to add.

[sander1095]

I looked through the codebase, and I saw 250 Assert statements, and 159 Should() statements (fluentassertions).

In my projects I always only use FluentAssertions. There is nothing wrong with using both, but I am curious what the maintainers would like in these sort of cases.

[alallema]

Hi @sander1095,
It would be nice to clean the test indeed.

So why do we use BeGreaterOrEqualTo(1)? In this case, we should be using Be(1).

In this case, you are right, it should be Be(1) sometimes in test cases we keep the BeGreaterOrEqualTo() but more for search or task results when it is not possible to know the exact numbers.

In my projects I always only use FluentAssertions.

Ans I agree too it would be nice to use only FluentAssertions if possible

[brunoocasali]

I'm ok to refactor and use only FluentAssertions or no FluentAssertions at all.

About the matching, it is sometimes hard to predict the right amount of what we should assert in those integration tests. We know this is not good, but we will address them in all of our SDKs in the future (after v1) otherwise is a real pain to deal with minor updates during the pre-release time 😅.