Tuesday, March 24, 2009

Code Contracts

Code Contracts provide a language-agnostic way to express coding assumptions in .NET programs. The contracts take the form of preconditions, postconditions, and object invariants. Contracts act as checked documentation of your external and internal APIs. The contracts are used to improve testing via runtime checking, enable static contract verification, and documentation generation.

Code Contracts bring the advantages of design-by-contract programming to all .NET programming languages.


The benefits of writing contracts are:

Improved testability
  • each contract acts as an oracle, giving a test run a pass/fail indication.
  • automatic testing tools, such as Pex, can take advantage of contracts to generate more meaningful unit tests by filtering out meaningless test arguments that don't satisfy the pre-conditions.

Static verification tools can takes advantage of contracts to reduce false positives and produce more meaningful errors.


API documentation Our API documentation often lacks useful information. The same contracts used for runtime testing and static verification can also be used to generate better API documentation, such as which parameters need to be non-null, etc.


Using a set of static library methods for writing preconditions, postconditions, and object invariants as well as two tools from Micrsosoft:

  • ccrewrite, for generating runtime checking from the contracts
  • cccheck, a static checker that verifies contracts at compile-time.

The plan from Microsoft is to add further tools for

  • Automatic API documentation generatio
  • Intellisense integration

The use of a library has the advantage that all .NET languages can immediately take advantage of contracts. There is no need to write a special parser or compiler. Furthermore, the respective language compilers naturally check the contracts for well-formedness (type checking and name resolution) and produce a compiled form of the contracts as MSIL. Authoring contracts in Visual Studio allows programmers to take advantage of the standard intellisense provided by the language services. Previous approaches based on .NET attributes fall far short as they neither provide an expressive enough medium, nor can they take advantage of compile-time checks.

Contracts are expressed using static method calls at method entries. Tools take care to interpret these declarative contracts in the right places. These methods are found in the System.Diagnostics.Contracts namespace.
• Contract.Requires takes a boolean condition and expresses a precondition of the method. A precondition must be true on entry to the method. It is the caller's responsibility to make sure the pre-condition is met.
• Contract.Ensures takes a boolean condition and expresses a postcondition of the method. A postcondition must be true at all normal exit points of the method. It is the implementation's responsibility that the postcondition is met.

Watch this space for more developments in this area.

Source: http://research.microsoft.com/en-us/projects/contracts/

No comments: