Are unit-tests needed when you have code contracts?

Question

If you're developing application using the code contracts, you may know, that this concept was introduced in Eiffel programming language.

I have become very confused after trying this concept in my C# application using System.Diagnostics.Contracts.

The main question for me is the next:

Are unit-tests really needed, if you have code contracts?

One of the major differences, that unit-test frameworks usually don't provide, is the possibility to call private methods (except MS fakes library with its shims). It's done, because of supporting composition & the idea, that private methods are covered by public method calls.

As for the code contracts, I can declare Contract.Requires, Contract.Ensures for private methods.

So, why do I need unit-testing, when I have code-contracts, which behavior is very similar.

Thanks

Answer 1

You surely need Unit testing. With code contracts, you can only have your static contract verification. There's much more you can do when running your code.

For example, say you are testing a class that depends on IConnectionProvider. What happens when your GetConnection throws? Code contracts won't help you with that.

Ideally you'd be testing the public methods of your class with different inputs, and verifying that it behaves as expected. This will help you find bugs, and in the long run, design better code.