Consider types assignable to open generics (#954)

[mdonoughe]

I think I did this right, at least for BeAssignableTo. Base types and interfaces are searched for matching generic types.

Should BeDerivedFrom do the same thing but disallowing interfaces?

#954

IMPORTANT

• The Pull Request is targeted at the master branch.
• The code complies with the Coding Guidelines for C# 3.0, 4.0 and 5.0.
• The changes are covered by a new or existing set of unit tests which follow the Arrange-Act-Assert syntax such as is used in this example.
• If the contribution affects the documentation, please include your changes to documentation.md in this pull request so the documentation will appear on the website.

[dennisdoomen]

Only minor comments and suggestions. Feel free to ignore them or apply then. I use these emojis.

[dennisdoomen]

🙃 I personally find all these intermediate return statements a more difficult to read.

[mdonoughe]

Is this better now?

[dennisdoomen]

🙃 We normally use the When_...._it_should_.... format for all our tests.
🤔 I don't get the when constructed. We're not constructing anything here, right?

[mdonoughe]

Microsoft uses the term "constructed" when referring to a generic type that has its arguments filled in: https://docs.microsoft.com/en-us/dotnet/api/System.Type.IsConstructedGenericType?view=netframework-4.7.2 . I hadn't seen it before either.

[dennisdoomen]

I guess we're missing some kind of context for a group of specs so that we don't have to repeat the cause and effect.

[dennisdoomen]

🙃 It feels like the name is missing a verb or something.

[mdonoughe]

I was trying to emulate the "When_its_own_type_instance_it_succeeds" pattern the other BeAssignableTo methods were following without making the names super long.

[mdonoughe]

I've added in support for BeDerivedFrom too.

[jnyrup]

Thanks for taking up this issue 👍
If you have appetite for more, we need to get the following assertions consistent with respect to open generics.
Such that e.g. obj.Should().BeAssignableTo(typeof(IInterface<>)) and obj.GetType().Should().BeAssignableTo(typeof(IInterface<>)) have the same behavior.

TypeAssertions

• [Not]Implement
• [Not]BeDerivedFrom
• [Not]BeAssignableTo

ReferenceTypeAssertions

• [Not]BeOfType
• [Not]BeAssignableTo

[mdonoughe]

BeOfType already had open generics.

Is there a convention for both BeAssignableTos to use the same logic?

[jnyrup]

Yes, but NotBeOfType does not.

I'm not sure I understand your question.
If you're asking where to put shared logic, I would put it in TypeExtensions.cs.

[jnyrup]

Don't know if this is WIP, but BeAssignableTo<T> should probably call BeAssignableTo(Type) instead?

[mdonoughe]

It probably should, but it doesn't seem to make any difference since you can't pass open generics to methods like that. I assumed it did already.

[mdonoughe]

Actually should it? BeAssignableTo<T> casts the result to T, so for cases where it wouldn't match BeAssignableTo (shouldn't be any?) it would fail to cast even if it relied on BeAssignableTo to do the assertion.

[dennisdoomen]

@jnyrup can this be merged?

[jnyrup]

It looks very good now and feature wise could be merge.
But I would like to have both a positive and a negative test for BeAssignableTo, NotBeAssignableTo and NotBeOfType from ReferenceTypeAssertions when the expectation is an open generic.

[dennisdoomen]

Maybe it's better to request changes then. It makes the state of the PR more visual.

[jnyrup]

I would like to have both a positive and a negative test for BeAssignableTo, NotBeAssignableTo and NotBeOfType from ReferenceTypeAssertions when the expectation is an open generic.

[jnyrup]

@mdonoughe You can ignore the single failing test.
Testing timing related test is sometimes unstable, and all except one target framework that test passed.
I'm very satisfied now, so if you're good to go, I'll hit the merge button