Microsoft Code Contracts – do we need it?

As probably some of you know, code contracts concept is very nice. It allows on checking if the rules we need are fulfilled thanks to which we could sleep safely. First time it was introduced in Eiffel language, you could read more on that on Design by Contract Wikipedia page. Looking through Wikipedia page, we could find:

Design by contract (DbC), […] is an approach for designing software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants.”

Source

Wait for a moment, isn’t that matching to our concept of unit testing? Just think about that:

  • in both cases we want to check for assertions
  • for both we want to be sure that tests will fail if condition is not fulfilled

The big benefit is that you separate concepts of checking if your code is fulfilling contract in your unit tests, avoiding frequent usage of checks in runtime which could impact your performance.

Personally, having that in mind I cannot find real value of Code Contracts that Microsoft has created, still spending money on that. I don’t believe it could replace unit tests anyway, just being addition to that. On the other hand, I believe unit tests could replace code contacts easily allowing developers on good sleep all the time 🙂

Advertisements

One thought on “Microsoft Code Contracts – do we need it?

  1. I’m compelled to disagree. I’m thinking you haven’t used Code Contracts on a real project yet, or I think you would recognize other values it adds.

    I agree that a value of unit tests and a value of code contracts intersect, but code contracts facilitate more than assertion. It allows code to self document contracts that can: be statically verified at compile time, presented to developers consuming the contract through intellisense and automatic extension of documentation, and it can create exceptions during debug that can be optimized away in release mode. It does all of these things in one line of code, whereas accomplishing this yourself involves: conditional compilation directives, if (argument test) throw, manual XML documentation, and manual creation of a unit test to ensure each possible combination of parameter nullness is tested.

    If anything, I would think that it expresses many of the things that ought to be tested, yes, but it compliments unit tests well, especially considering the possibility that you would provide a library to people who don’t have the source code. Not only do they get the intellisense and documentation benefits, but if they use code contracts in their project it can be used to verify not only their own internal contracts, but also statically verify if they’re disobeying the contracts expressed in the 3rd party library they bought from you. I’ve not seen anyone give their customers their internal unit tests as a form of documentation (“Oh, you’ll find all the contracts of what parameters can be null or not and whether or not code returns nulls in here”), so it isn’t wholly sufficient in shared/reused code or distributed library projects.

    Even assuming you write the documentation yourself, you still don’t get static checking which saves me a ton of time, since my unit test suite is massive and takes forever to run; finding out I forgot to consider an assumption or it realizing before my tests ever start running that I’m going to get an ArgumentNullException, for sure, are great additions to my tools. It might even be useful for *generating* unit tests, at some point. Either way, unit tests are internal and do not present themselves as well organized contract documentation (though they can function for it, if your unit tests are complete to every aspect of the contract and cover every range of possible parameter values and combinations of nullability or not). The difficulty there is that the information is scattered all over the place. I would effectively need to read many many lines of code in a single uber-test (which isn’t a “unit” test) or I have to read many separate test methods, whereas the code contracts appear immediately at the top of the method and express themselves in a single line.

    In the end, if you ever write “if (parameter value) throw ” you *are* writing code contracts. The new tools just allow you to express them in a more readable way (“Contract.Requires(parameter value)”) that can be consumed more readily by automated tools, including their own static verification tools. Apart from requirements and guarantees (ensuring return values will never be null, for example), it also pushes you to state your assumptions, which unit tests do not document well. The verifier also recommends contracts it can infer, which helps you to be more complete in your documentation coverage.

    Eek, sorry for the rant :-/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s