From: Rafael Vieira <raff_uk@...>
Date: 2007-03-20T18:27:01+09:00
Subject: Re: ruby programming best practice

David Vallner wrote:
> James Edward Gray II wrote:
>>>> With automated unit testing, the benefits of static typing, bounds
>> 
>> I quit reading right here.
>> 
>> It's *not* reimplementation!
>> 
>> You need to be testing your software anyway, even if you are using the
>> perfect language that protects you from all your errors.  Since you're
>> doing that anyway, this is just a free side effect for your good habits.
>> 
> 
> That's what the original quote states though. "You typically write tests
> for these scenarios anyway.", amongst those scenarios being some that
> can be checked using static analysis in a suitably more predictable
> language. If you're using a dynamic language, and covering checks for
> those scenarios in unit tests, then you're reimplementing what a
> contract-verifying compiler / runtime would catch in them, quite simply
> because without such a compiler / runtime you don't have much choice if
> you want your code to be robust along those axes. In and of themselves,
> unit tests are (supposed to be) a complement to (substitute for the
> absence of) language-provided unit contract checks - since they're
> arbitrarily user-defined, they are to be used to check dynamic aspects
> of those contracts that statical analysis (if there is any) can't.
> Generally the unit testing methodology gets more awkward when you need
> to test complex emergent behaviour that comes from the cooperation of
> these units, and equating them to "testing your software" is just
> misleading.
> 
> If you gain enough coverage for dynamic unit contracts, I'll admit it's
> probably safe to assume that you have the more trivial checks that
> statical analysis can do covered - in that case you can do away with
> anything that would be reimplementing a compiler's checks. However, such
> coverage takes nontrivial effort to create and maintain, and usually at
> least I want to be able to reason on a code unit's correctness at least
> to some extent while expending no / minimal effort on test code for the
> "D'oh" type of error. For example, I'd very much like if I could tag a
> variable to disallow assigning a nil into it and raise an exception when
> that happens -immediately-, instead of getting a NME someplace else in
> the code. I'd be hard to convince removing that check into a unit test
> would be more concise than having language support for it.
> 
> David Vallner
Hi David,

Im looking for Ruby Programmer to work in Bratislava/SK.
Please let me know if you are interested or if you know someone.

Thanks and sorry for any inconvenience.

Rafael Vieira - IM: raff_uk@hotmail.com

-- 
Posted via http://www.ruby-forum.com/.