I tried to find if there's a similar question but didn't even know what keywords should I use :)

I got a method in an interface accepting an other interface as a parameter:

bool CanDoIt(AnInterface subject)


One of the implementations needs to fulfill the requirement that the method should return false for all concrete types (implementing AnInterface) different than X.

Simple implementation could look like (didn't wrote it since got no UT for that):

bool CanDoIt(AnInterface subject)
{
    if(!(subject is X)) return false;
    else ...
}


I know that this is a code smell accepting an interface and then checking it's concrete type - unfortunately for now I got to stick with it.

I would like to write a test that would check if the requirement is implemented correctly. So that test would fail if someone would ever add a new type implementing AnInterface and changed the method not to meet the requirement. 

If writing such a test isn't possible then what can I do to consider the coded tested? Would writing a test using few exemplary types would be enough, or is it better not to write it at all?

0 is false because they’re both zero elements in common semirings. Even though they are distinct data types, it makes intuitive sense to convert between them because they belong to isomorphic algebraic structures.


0 is the identity for addition and zero for multiplication. This is true for integers and rationals, but not IEEE-754 floating-point numbers: 0.0 * NaN = NaN and 0.0 * Infinity = NaN.
false is the identity for Boolean xor (⊻) and zero for Boolean and (∧). If Booleans are represented as {0, 1}—the set of integers modulo 2—you can think of ⊻ as addition without carry and ∧ as multiplication.
"" and [] are identity for concatenation, but there are several operations for which they make sense as zero. Repetition is one, but repetition and concatenation do not distribute, so these operations don’t form a semiring.


Such implicit conversions are helpful in small programs, but in the large can make programs more difficult to reason about. Just one of the many tradeoffs in language design.
