Design by Contract in .NET

Marcin Celej — Thu, 16 Feb 2006 06:17:00 GMT

Design by Contract is a methodology that was populated by Eiffel language. The DbC ideas have common aims with Test Driven Development (TDD). Both focus on software quality and tests written with code in parallel.

The idea of DbC is based on contract - contract between client code and service. Each class is a service that provides set of methods (nothing new). Each method call is a client. Contract between them says that if the client satisfies some preconditions then service will ensure some postconditions. That's all. The contracts (or assertions) should be declared easily with the method as there may be lots of them. C# does not support such assertions easily. Some people do it in this way:

public decimal AccountBalance
{
    [Ensures("result > 0")]
    get;
    [Requires("value > 0", "Balance must be greater than zero")]
    [Ensures("AccountBalance == value")]
    set;
}

The Requires attribute represents precondition assertion and the Ensures attribute checks postconditions. The notation is not perfect here but it shows how the assertions (tests) are embedded within code. Let's ignore some performance implications of the methodology and think how it simplifies test-centric development.

Unfortunatelly there is no good implementation of the methodology in .NET yet. There is a research project in Microsoft that tries to introduce such language (Spec#) to the .NET platform. Sample assertions in the Spec# looks like this:

public class ArrayList
{
    public void Insert(int index, object value)
        requires 0 <= index && index < Count
        requires !IsReadOnly otherwise NotSupportedException
    {
        ...
    }
}

As you can see the difference is in syntax only, not in idea of the methodology. So Microsoft goes this way.

I believe the DbC is a powerful mechanism that can save you tears (as many other test-centric mechanisms). I hope the Spec# will become commonly used C# extension (I only played with it yet). Finally: everyone intrested in TDD methodologies should carrefully overview the DbC techniques.

Some principles of Unit Test creation

Marcin Celej — Fri, 03 Feb 2006 06:58:00 GMT

I am big fun of Test Driven Development (TDD). I recently read quite good article about unit testing: Write Maintainable Unit Tests That Will Save You Time And Tears. Here is an extract of the article:

Fail First (before you write piece of logic, write fail test first) - do not write any test, but simulate production environment that will use the logic so the test will remain as regression test of your logic.
Requirements conflict (old UT fails when new funct. is introduced) - remove or enhance old UT.
If you can remove a line in your tested class and all tests still pass - you have not enough unit tests.
Remeber that tests must be maintained as any other code - so 'Keep It Simple, Stupid' (KISS)
Make tests easy to run (or at least some subset of tests) so developers can run it often.
Do not let peaple to stop trust the tests - the less false-positives in failed tests the better.
Test only public interface of component.
Reuse your creation, manipulation, and assertion code when possible.
Don't create instances of classes directly inside a unit test - use factory even more than normally.
Refactor unit tests - mainly to KISS them .
Avoid dependencies between tests - any test should work run in any order .
Create readable tests - write comments in Asserts and in UT. Write descriptive method names (even very long). Use local variables in Asserts. Use constants. UT should be readable like a book.

Here is an extract of one of many UT articles. I would like to create some check list to be able to do code review of unit tests based on the list and on the principles contained in it.