I got into Design By Contract with Obvious (http://obvious.retromocha.com)
in Ruby and ended up writing my own concept of contracts in Ruby. I find
them to be useful simply because they give you runtime type guarantees that
you don't get normally with Ruby. Without a stronger notion of interfaces
in Ruby, you have to lean harder on your unit tests to provide some kind of
guarantees about certain behaviors. With contracts, you actually write a
lot fewer tests because your contract specifies and ensures more correct
input and output.

Obvious contracts were really simple, but I think the idea could be taken
further to handle things like validation.

In general, with stronger guarantees around input and output, you have to
write fewer tests.

-Brian



On Tue, Jul 22, 2014 at 7:05 AM, Wayne Conrad <kf7qga / gmail.com> wrote:

> On 07/22/2014 12:12 AM, Adam Wenham wrote:
>
>>
>> I'm been reading The Pragmatic Programmer and have come across the
>> concept of 'Design by Contract' (http://en.wikipedia.org/wiki/
>> Design_by_contract), which is a concept I haven't come across before.
>>
>>
> It is good to learn Design By Contract (DBC).  Thinking about invariants,
> pre-conditions and post-conditions helps in making classes which work well
> and are easy to use.  You might profit from using DBC as a learning
> exercise.
>
> I do not favor the addition of DBC conditions for most production code,
> primarily because unit tests provide most of the same value that conditions
> provide, but without bloating the code.
>
> Wayne Conrad
>
>