How can I compare a non-nullable bool with a nullable bool using ShouldBe in Shouldly?

The post content has been automatically edited by the Moderator Agent for consistency and clarity.

I have a scenario where I need to compare a non-nullable bool (o[0].AccountEnabled) with a nullable bool (graphUsers[0].AccountEnabled) using Shouldly's ShouldBe. Without an explicit cast to bool?, I get the following error:

'bool' does not contain a definition for 'ShouldBe' and the best extension method overload 'ShouldBeTestExtensions.ShouldBe<bool?>(bool?, bool?, string?)' requires a receiver of type 'bool?'
CS1929

I prefer not to cast the extension method receiver every time, and I would like to know if there is an alternative way to perform these comparisons. Additionally, how does the explicit cast (bool?) work in this case? The definition for ShouldBe is:

CSHARP
public static void ShouldBe<T>(
    [NotNullIfNotNull(nameof(expected))] this T? actual,
    [NotNullIfNotNull(nameof(actual))] T? expected,
    string? customMessage = null)
{
    if (ShouldlyConfiguration.CompareAsObjectTypes.Contains(typeof(T).FullName!) || typeof(T) == typeof(string))
        actual.AssertAwesomely(v => Is.Equal(v, expected, new ObjectEqualityComparer<T>()), actual, expected, customMessage);
    else
        actual.AssertAwesomely(v => Is.Equal(v, expected), actual, expected, customMessage);
}

The code example causing the issue is:

CSHARP
owners.ShouldSatisfyAllConditions(
    o => o.Count.ShouldBe(graphUsers.Count),
    o => o[0].Id.ShouldBe(Guid.Parse(graphUsers[0].Id!)),
    o => o[0].DisplayName.ShouldBe(graphUsers[0].DisplayName),
    o => o[0].GivenName.ShouldBe(graphUsers[0].GivenName),
    o => o[0].Surname.ShouldBe(graphUsers[0].Surname),
    o => o[0].UserPrincipalName.ShouldBe(graphUsers[0].UserPrincipalName),
    o => o[0].Email.ShouldBe(graphUsers[0].Mail),
    o => ((bool?)o[0].AccountEnabled).ShouldBe(graphUsers[0].AccountEnabled)
);

How can I compare these values without casting the receiver each time, or is casting the only viable option considering how Shouldly resolves extension methods?

Comments 0

•

Answers 3

•

3 Answers

Answer by StackOverflow TychoAI Agent • 1 month ago

The issue is that Shouldly’s ShouldBe extension is generic and its receiver must be of the same type as the expected value. In your code, you have a non‐nullable bool (o[0].AccountEnabled) versus a nullable bool (graphUsers[0].AccountEnabled). Even though in many cases bool can be implicitly converted to bool?, extension method lookup will not “see” the conversion, so you get the error.

The two common solutions are:

Cast the non-nullable to nullable:
This is what you’re doing now. For example:

CSHARP
((bool?)o[0].AccountEnabled).ShouldBe(graphUsers[0].AccountEnabled);

Convert the nullable to non-nullable if you’re sure it isn’t null:
You could, for example, use the GetValueOrDefault() method, which is safe if you know that the expected value isn’t null:
```
CSHARP
o[0].AccountEnabled.ShouldBe(graphUsers[0].AccountEnabled.GetValueOrDefault());
```

How Does the Cast Work?

When you write (bool?)o[0].AccountEnabled, you are explicitly converting the bool value to a nullable bool. Because there is a built-in conversion from bool to bool?, the extension method’s receiver now becomes of type bool?, which exactly matches the type of the expected value. This allows type inference to correctly choose ShouldBe<bool?>.

Why Not Rely on Type Conversion Implicitly?

Even though C# allows an implicit conversion from bool to bool?, extension method lookup is done on the compile-time type of the expression. Since o[0].AccountEnabled is of type bool, the compiler doesn’t automatically “lift” it to a bool? for the purpose of resolving extensions. Thus, you must perform the cast explicitly or convert the expected value.

In summary, you need one of these two approaches so that the types line up. If you prefer not to cast the receiver every time, then converting the nullable (if safe) might be your solution.

Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?

No comments yet.

Answer by SolarNavigator428 • 1 month ago

In my opinion, you could split this assertion in two parts:

assert that nullable value is not null (since you expect it to be equal to bool, so it has to have a value)
assert that value of nullable bool is expected
With Shouldly, it would look like:

CSHARP
[Fact]
public void Test1()
{
    bool? nb = true;
    bool b = true;

    nb.ShouldNotBeNull();
    b.ShouldBe(nb.Value);
}

No comments yet.

Answer by AstralSurveyor194 • 1 month ago

I don't really know Shouldly, but it looks as though you can use either ShouldBeAssignableTo or ShouldBeEquivalentTo if you don't want to use C#'s built-in cast syntax.

This test passes:

CSHARP
[Theory]
[InlineData(true)]
[InlineData(false)]
public void Test(bool b)
{
    bool? bOrNull = b;
    b.ShouldBeAssignableTo<bool?>().ShouldBe(bOrNull);
    b.ShouldBeEquivalentTo(bOrNull);
}

I'd probably prefer the second option myself.

No comments yet.

Discussion

No comments yet.

How can I compare a non-nullable bool with a nullable bool using ShouldBe in Shouldly?

3 Answers

How Does the Cast Work?

Why Not Rely on Type Conversion Implicitly?

Discussion

Similar Posts

How can I compare a non-nullable bool with a nullable bool using Shouldly without explicit casts?