Description

I came across this issue recently and the discussion in #1768 highlights the confusion as well.

The names BeUpperCased() and BeLowerCased() imply to me an assertion that the subject string is in a form producible by ToUpper() or ToLower(), respectively. The example below illustrates the semantics I expect.

I'm going to suggest a breaking change to include in the next major version of FluentAssertions. I'm happy to work on this if accepted.

Can we change the implementation of BeUpperCased() and BeLowerCased() to match the semantics suggested by their names?

NotBeUpperCased()/NotBeLowerCased() would then change to assert that there are some lower-case/upper-case letters in the string.

We could add new assertions, maybe BeAllLowerCase()/BeAllUpperCase(), with the current semantics of the existing methods.

Complete minimal example reproducing the issue

var someString = /* any string value */;

var result = someString.ToLower();

result.Should().BeLowerCased();

Expected behavior:

I would expect this assertion to pass for any value of someString.

Actual behavior:

The assertion fails if there are non-letter characters in the string.