That’s a good point. As I stated, Code Contracts are no master solution. Contracts define behavior on code, but those definitions could be insufficient or incorrect as well. This brings unit tests to mind.

And I see the problem you mentioned: duplicating program logic in contracts is not a suitable way. In limited cases this would work and you can model implications in the form of: “if input is x, output should by y”. But in more complex cases (take complex algorithms, for example a sorting algorithm), this would be no solution. I agree with you, that in this case a unit test is the correct answer. The problem of unit test remains: it can only test one input/output pair (or a limited set), but in the case of expressing semantic logic/behavior it is the right tool. Thank you for pushing in your ideas on that, I’ll further make my mind up on that and your opinions are welcome everytime.

Cheers, Matthias

sorry to contradict you somewhat, but IMO code contracts and unit testing have a somewhat more complex relationship than your comments indicated.

Granted, there is a certain amount of overlap and some unittests could quite well be expressed as contracts (because soo far they were the only means to check those contracts). But then, contracts are about stating and ensuring certain guarantees about the code, while unittests are about behaviour or the correctness of the implemented algorithm.

To make my point clear, have a look at this example (pseudo code!):

double Sqrt(double x)
{
requires: x>=0
ensures: ret>=0
ensures: ret<x || ret==0

return x/2
}

This would be formally correct and state all the sensible guarantess, but dividing by two is clearly not the same as a square root. To ensure the correctness, you would still need a unit test, checking if x==Sqrt(x)*Sqrt(x). And you would not want to dupplicate the logic of your code as a contract.

Just my 0,02€
AJ.NET

You’re right. Contracts are more expressive than unit tests in the sense, that with the static checker you have verification over all code parts and all value ranges. With unit tests you’ve just some test cases and need defined value pairs (input and expected output) for that. But often you forget something to test…

Regarding the combination of TDD and DbC I want to make my mind up in the following days and weeks for myself. DbC has not only advantages! The behavior that you defined is guaranteed, but who says that this is the behavior that you or a user expected? It’s very likely that you forget contracts or define wrong contracts or have errors in your contracts… and then? Testing can do very well in this case, I think. Another problem is the complexity of defining contracs. Many not so advanced developers would be overwhelmed by that. Let me do a little bit more research on DbC+TDD, I hope to have some stronger ideas soon…