So, you are technically correct that Code Contracts will throw an ArgumentNullException
if any one of your arguments are null
.
However, it would still be a good idea to unit test your preconditions. It's not so much to ensure that Code Contracts is working correctly—it does! But it's to ensure that you actually specified the right contract!
I am saying this from personal experience. I was writing a blog post on Code Contracts and unit testing. And while writing the sample code, I stated a precondition on a method. I ran the unit tests and a few tests failed. I was a bit taken aback. What happened? Well, silly me, I reversed the Boolean condition I wanted to enforce. Oops. Thanks to unit tests, though, this was caught and easily corrected.
Also, Code Contracts is not only about guaranteeing that parameters don't come in null (in your example). Code Contracts also function as a form of communication to clients of your code. They tell consumers of your library that, if they meet the stated preconditions, you guarantee that the method will execute successfully and satisfy any object invariants and/or stated method postconditions.
While Code Contracts can go a long way in helping you to write code that doesn't fail, it's not a silver bullet. It can't catch all logic errors (Code Contracts won't help you avoid infinite loops, for example). So, unit tests are still very much an important part of the development process even when using Code Contracts.