Posted Jim Weirich OSCON 2006 video presentation

Ruby
1

For anybody interested, I posted the talk about Design By Contract in
Ruby
that Jim W. gave @ OSCON 2006 on my blog.

I have 3 or 4 more that I am in the process of uploading.
I am waiting for a written release from some of the presenters :slight_smile: before
I
make them public.
Last thing I need is to get sued :smiley:

Enjoy :smiley:

2

On Feb 6, 4:14 pm, ā€œDiego Scatagliniā€ [email protected] wrote:

For anybody interested, I posted the talk about Design By Contract in Ruby
that Jim W. gave @ OSCON 2006 on my blog.Best Online Casino in Australia | Top Licensed Casinos for Gamblersā€¦

I have 3 or 4 more that I am in the process of uploading.
I am waiting for a written release from some of the presenters :slight_smile: before I
make them public.
Last thing I need is to get sued :smiley:

Interesting presentation.

The more these test/specification/dbc system evolve the more they seem
like double-entry bookkeeping. Arenā€™t we just writing the code twice
but from two differnt perspectives and seeing if they match up?

T.

3

Trans wrote:

The more these test/specification/dbc system evolve the more they seem
like double-entry bookkeeping. Arenā€™t we just writing the code twice
but from two differnt perspectives and seeing if they match up?
Mostly, yes. (Though usually the test is a drastic simplification for a
specific example.) Thrice if you do acceptance testing. Is that a bad
thing?

Devin

4

On Feb 6, 11:18 pm, ā€œDiego Scatagliniā€ [email protected] wrote:

I believe one of the main differences is that DBC is more of a runtime
check.

Perhaps. But one of the first thing I thought when I saw Jim run it is
whereā€™s the ā€œā€“debugā€? I donā€™t see why youā€™d want this to happen in
production.

T.

5

On 7 Feb 2007, at 05:28, Trans wrote:

On Feb 6, 11:18 pm, ā€œDiego Scatagliniā€ [email protected] wrote:

I believe one of the main differences is that DBC is more of a
runtime
check.

Perhaps. But one of the first thing I thought when I saw Jim run it is
whereā€™s the ā€œā€“debugā€? I donā€™t see why youā€™d want this to happen in
production.

Iā€™ve not watched the presentation, but with experience of other DBC
systems I imagine the reason would be that contract violations can
happen in production - and knowing about them is generally a good
thing :slight_smile:

Cheers,

Adrian

6

On Feb 6, 2007, at 6:18 PM, Trans wrote:

The more these test/specification/dbc system evolve the more they seem
like double-entry bookkeeping. Arenā€™t we just writing the code twice
but from two differnt perspectives and seeing if they match up?

Given that double-entry bookkeeping is often cited as one of the
subtle advancements that led to global the dominance of the Western
world, Iā€™m not sure this is a bad thing.

But.

ā€œYes and noā€. For a single piece of code, itā€™s generally a lot
simpler to test that the code did the right thing than to write the
functional code itself. If you add in edge cases, the problem
multiplies: itā€™s a lot easier to write 10 individual test cases,
each for one edge case, than to write one piece of functional code
that elegantly (or even inelegantly) handles all the edge cases. As
your app grows, this aspect grows by leaps and bounds.

Iā€™ve been asked something along the lines of ā€œwell how do we know
that the test code doesnā€™t have bugs in it?ā€. The answer is that we
donā€™t. However, think of this as a probability problem. The
following are gross oversimplifications, but should get the gist.

  • If you have one test case per chunk of code, and that test case
    also has a 10% chance of being wrong, and if theyā€™re wrong in exactly
    the same way, then you have an 81% chance that the code executes
    correctly and tests cleanly, an 18% chance that the test fails (9%
    false positive, 9% false negative), and a 1% chance that the test
    passes incorrectly. Since a failure will likely to look through your
    code until you either find whatā€™s wrong in your code or your test,
    then youā€™ve just dramatically decreased the chance of an uncaught bug.

  • As code increases the likelyhood of bug-free code decreases
    exponentially with the amount of code. However, since tests often
    must implicitly test things other than the specific thing theyā€™re
    testing, the likelihood of bugs remaining uncaught also decreases at
    an exponential rate.

There are limits to all of this, and I do think that people are prone
to putting too much faith in automated testing, but it still runs
circles around a lack of it.

-faisal

7

I believe one of the main differences is that DBC is more of a runtime
check.