Code Contract First And Unit Test Second

This is what I (NatPryce) do instead of CodeUnitTestFirst when I use a language that supports DesignByContract, such as the EiffelLanguage.

1. Specify the required interface of the class as a contract. This is done piecemeal (no BigDesignUpFront), so as new features of the class are required I add contracts for new methods and modify the contracts of existing methods. Don't write a contract for behaviour if YouArentGoingToNeedIt.
2. Write a unit test that verifies the implementation of the contract.
3. Implement, test and debug the class until the test passes.

Rationale

In languages without DesignByContract, XP uses a UnitTest to both specify the expected behaviour of a class (its contract) and test the implementation of the contract. Languages with DesignByContract separate the declarative specification of the contract from the test code that verifies its implementation (SeparationOfConcerns).

We want samples, please. In Eiffel. ;)

Ok, how about the usual Stack example. For readers who do not know Eiffel syntax:

• STACK [T] indicates that STACK is a generic class. The equivalent C++ would be stack<class T>.
• The feature instruction groups a set of features (methods and/or attributes) and defines their visibility. It's like a mixture of a C++ protection label and friend declaration. However, the features are also grouped in the class documentation in a section whose title is the comment associated with the feature instruction. ANY is the root of the inheritance hierarchy, and so "feature {ANY}," exports those features to any class in the system; it is the same as "public:" in C++.
• The creation clause declares which methods are constructors. A class can have multiple constructors with different names.
• "Result" is a local variable defined by the language to refer to the result returned by a method.
• The "old" qualifier in ensure clauses refers the value of the expression before the method was called.

First the contract:

class STACK [T]
    -- A stack.  We won't follow strict query/command separation 
    -- to help Java programmers understand what's going on :-)

creation
    make

feature {ANY}, -- Queries
    is_empty : BOOLEAN is
            -- Is the stack empty?
        deferred
        ensure
            is_empty = (count = 0)
        end

    count : INTEGER is
            -- How many items are in the stack?
        deferred
        ensure
            Result >= 0
        end

    top : T is
            -- Returns the top of the stack
        require
            not is_empty
        deferred
        ensure
            top = item(1)
        end

    item( n : INTEGER ) : T is
            -- Peek at items lower down the stack.  Items are indexed from 1
            -- with lower indices being nearer the top of the stack. (That's
            -- the way Eiffel does it; sorry Java and C fans!)
        require
            not is_empty
            n >= 1 and n <= count
        deferred
        end

feature {ANY}, -- Commands
    push( new_item : T ) is
            -- Pushes a new object onto the top of the stack
        deferred
        ensure
            not is_empty
            count = old count + 1
            top = new_item
            count > 1 implies item(2) = old top
        end

    pop : T is
            -- Pops the top off the stack
        require
            not is_empty
        deferred
        ensure
            Result = old top
            count = old count - 1
            old count > 1 implies top = old item(2)
        end

    make is
            -- Makes an empty stack
        deferred
        ensure
            is_empty
        end
end

Second, the tests... Phew I'm tired after that. Anyone want to write an EiffelUnit test?

Third, replace those deferred features with implementations. I'll leave that as an exercise to the reader.

--NatPryce

I have discovered, while using this technique, that EiffelUnit does not really act in the way I would like. I think it's too close a copy of JavaUnit. When contracts are separated from the test driver, there is less need for assert statements because the postconditions and invariants already express those assertions. However tests need to document how they are exercising the contract and this information should be collected by the testing framework. When errors are reported, I want to see "test X, line Y, violated precondition of O: predicate P was false", or something like that

--NatPryce

We used to do a variant of this in Smalltalk, and I still do something like it in Java. First I create the "stub" class that gives only the external interfaces -- no implementation. Then I code the UnitTest. Then I run the UnitTest and fill in the stubs...

KyleBrown