How to combine defensive programming techniques together?

Question

The question I want to ask you is quite wide but in the same time it's very concrete. First, I have to say, that I mostly interested in answers which are applicable in the .net environment.

Well, I want to increase the level of the code I produce. Now I mostly use the TDD and the static code analysis to ensure that my code is correct. Recently I've listened to Dino Esposito's speech about code contracts and now I want to use it in conjunction with other techniques. While listening to Dino I've also recalled the Debug.Assert() and Trace.Assert().

To be concrete I will ask several questions:

• How should I write the contracts and unit tests to complement each other?
• Should I use code contracts in every method or in public methods only?
• Should I prevent the usage of Debug.Assert()? When it's OK to use them? (For example, notice that invariants in .net are checked only on public method/property exit. So, is it OK to make some checks in the middle of the method by simple Assert()?)
• Could you please recommend me the open source project where all these techniques are properly used because a picture paints a thousand words?

Answer 1

You should start by studying the (rather good) manual for Contracts.

• it has a chapter and sample code about unit test integration. Much more info if you follow the Pex links.
• use contracts in all public members allways. For private members: sometimes.
• you could still use Debug.Assert() but Contracts.Assert() would be the more logical choice.
• sample projects... Don't know any. But do look at the contracts defined for the BCL.

Answer 2

I would fully embrace Contracts as in the preview blogs and by reading the longer pdf doc.

Contracts is not just for public functions. The big deal is that it provides a way for the compiler to reason about the code. So use it in all your functions as appropriate. That gives you the maximum benefit. Only using it in public functions is like saying you are only testing top level functions. Its wrong.

Your function test cases would mop up whatever logic still needs testing in the function after the Contract pre / post and invariant calls do their thing.

Be clear about the 3 usage scenarios, which one works for your code, and its issues. Ideally you can have them running in your production code and then scale back based on performance testing.

Make sure your generated docs include your contracts, its a nice benefit.

I also like the the DevExpress CodeRush and Refactor! Pro tools. They have specific refactorings for Contracts such as couple of clicks to turn input parameters into requires contracts etc. In addition they have some nice code analysis that will bump up your code quality in general.

You can peek at some code with Contracts here: https://searchcode.com/codesearch/view/14318515/

As for the whole best-practice enchilada all in one project. Well, I am looking at you Microsoft. Tsk.

Henk did a good job with the rest of your questions.