Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 0 down vote accepted

Some unit-testing systems allow you to add a unit test on an interface, with the testing system running that test on any class which implements that interface. On such a system, you could just write a test which calls CanDoIt and asserts that either it returned false or that AnInterface is X. A similar "test" would be, if using a contract framework, to add a contract like Contract.Promises(Contract.ReturnValue == (subject is X)); to CanDoIt.

If your system does not support either of these strategies, you may be better off asking a test-framework specific version of this question (on SO).

share|improve this answer
Thank You. I finally avoided the problem by redesigning, but mark this as a correct answer mainly due to mentioning those strategies. – Grzegorz Sławecki May 17 '13 at 11:27

You can't fix your design problem with testing.

You could write a test for every known implementation of AnInterface. When someone creates a new implementation, they would write a new test for CanDoIt.

It looks like CanDoIt should be a method on AnInterface. If you can, I suggest that you create aCanDoIt method on AnInterface and have your method delegate to AnInterface.

share|improve this answer

I don't think you can, because someone can easily write

bool CanDoIt(AnInterface subject)
    if(!(subject is X || subject is Y)) return false;
    else ...

and you don't know in advance about the new class Y.

Merely calling CanDoIt(someBogusClassThatImplementsAnInterface) would still fail

You should still call CanDoIt(someBogusClassThatImplementsAnInterface) to ensure someone doesn't simply remove the type check within CanDoIt(), but to get complete coverage you're going to have to remove the code smell and require CanDoIt() only accept X instead of anything that implements the interface. Since you've noted this is not an option, you're pretty much stuck.

share|improve this answer
Thanks for the answer - i expected that. So I added a question to the first post what to do in case when it's not possible. – Grzegorz Sławecki May 15 '13 at 20:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.