views:

236

answers:

1

Using the Code Contracts tools available in VS2010 Beta 2, I have defined an interface, a contract class for that interface and two classes that implement the interface.

Now when I come to test the code, I want to test the implementation classes so I know that their functionality is correct and I want to test the contract code so I know that my conditions are correct.

I could test each contract statement in each of the 2 implementation classes, but that is clearly redundant. I could just write the tests on one of these implementation classes, but that seems a bit wrong, how to choose between them, remembering which one to update as you change the contracts etc.

I'd like to test the actual interface contract class, but get all sorts of compile time warnings that the interface method I want to test is not available on the interface contract class. I know that there is post-compilation magic happening to actually inject the contract code into my implementation classes (which I can see in ILDASM), but when I inspect the interface contract class methods, they are there in the MISL, but empty.

I am missing something, or is what I want to do just not possible. If it is not, what is the "best practice" for this?

===Edit===

One suggestion here is to implement the interface in a class (internal to the test assembly) whose purpose is solely to test the interface contracts, sound sensible?

+1  A: 

Testing your contracts is like unit testing your unit tests. You don't do it because then you'd have to test the tests for your tests, etcetera.

Wim Coenen
I'd agree with this for straight forward contract statements, but if you are capturing business rules in object invariants, then you may wish to test these?
Colin Desmond