`ShouldBeOfType/ShouldBe` should test for type equality instead of "type or derived type"

At the moment ShouldBeOfType is implemented this way:

public static void ShouldBeOfType(this object actual, Type expected)
{
  if (actual == null)
    throw new SpecificationException ...

  if (!expected.IsAssignableFrom(actual.GetType()))
    throw new SpecificationException ...
}

Which is especially bad for specs like …

It should_not_allow_the_transfer = 
  () => exception.ShouldBeOfType<Exception>();

… because this spec would succeed for a thrown IOException too.

I think it would be better to use type equality:

  if (expected != actual.GetType())
    throw new SpecificationException ...

This would be of course a breaking change, which I think would be OK, because a) we are pre-1.0 and b) this would be the expected behavior of ShouldBeOfType.

We could add an additional ShouldBeAssignableTo (or ShouldBeOfTypeOrDerivedFrom) to provide the old behavior too (and a simple upgrade path).

Furthermore this would solve the inconsistency with ShouldNotBeOfType, which does already an equality-compare.

[fschmied]

FWIW, I’m for the breaking change because I think:

• it’s less surprising to me that ShouldBeOfType performs an exact match than that it performs an assignability match (possibly because I know other frameworks),
• the breaking change is explicit (i.e., it creates red tests after upgrading rather than silently doing the wrong thing), and
• code relying on the old behavior is easily fixed (you can search/replace if you want the old behavior).

BTW, an option to make the breaking change even more explicit would be to mark ShouldBeOfType [Obsolete] (with an explanatory message) and instead add ShouldBeOfExactType and ShouldBeAssignableTo.

[ulrichb]

@danielmarbach Yes, of course this would be a breaking change, and I tried to argue in the issue description why we should still go this way. The comparison with NUnit/xUnit is just one more argument.

Regarding “how we handle that gracefully”: We could provide a new method with the “type or derived type” behavior (see issue description) and document this in the release notes.