[LRUG] TDD (was: Ruby Contracting)

[Vahagn Hayrapetyan]

PS. My mum can code better than your dad!
PPS :-)

On Fri, Feb 20, 2009 at 2:40 PM, Vahagn Hayrapetyan <vahagnh at gmail.com>wrote:

> Code isn't for computers, it's for people, and if it's not readable by
>> people it isn't fit for purpose. Therefore I'd rather a codebase written
>> with an engaging and legible style that I can sit down and read as hard copy
>> than a mountain of specs and tests. YMMV.
>>
>
> I think we're communicating about different things here. Code readability
> is an asset, for sure. However the 2 important points to make are these:
>
> 1) Code has a managerial dimension to it. YOU may be great at reading your
> own (clean) code. This isn't enough for places where code serves other
> purposes than theoretical exercise. Generations of developers could
> potentially work with code that you write today.
> Saving money and effort by not supplying a test suite where appropriate
> could be the most costly decision in the long run (average employee loyalty
> today is about 6 months. So every 6 month, a developer could come in that
> inherits code that has grown since the previous developer, which he had
> inherited from the previous developer, etc. If an average new developer
> spends about double as much time trying to comprehend undocumented legacy
> code vs well-documented legacy code, it's a matter of simple arithmetic to
> produce a cost model that will demonstrate how much of a "saving" this would
> have been.)
>
> 2) Engaging and legible style is not a formal proof of correctness. Even if
> you did decide to supply each and every line of your code with formal proofs
> of correctness, that would only prove the *correctness of your programs*,
> not the *expected behaviour of your software*. In Object-Oriented systems
> change can occur at the structural seams of an application: how objects
> aggregate and reference each other. Say you have a class that manipulates
> objects of a certain interface type. Then, you refactor the existing object
> or you introduce a new object that implements the same interface type. Then,
> via an object reference somewhere, you reference "the wrong object".
>
> Your programs are still formally correct, but *at the architectural /
> structural level* your application has mutated. Now, unless one has
> special mental abilities for analyzing the configuration of objects in the
> VM at runtime, I wouldn't recommend relying on legibility and aesthetics to
> catch the errors or faults.
>
> Point being made: automated code testing is the most sustainable and
> ecological (both in digital and organic aspects of the word) way to ensure
> and document the expected behaviour of software. It can also be used as a
> productivity / creativity enhancement, but as you also seem to mean, that
> part depends entirely on the programmer.
>
> / Vahagn
>
>
> On Fri, Feb 20, 2009 at 1:01 PM, Eleanor McHugh <
> eleanor at games-with-brains.com> wrote:
>
>> On 19 Feb 2009, at 13:48, Vahagn Hayrapetyan wrote:
>>
>>> But what if eliminating ninety percent of those defects can be achieved
>>> without a test suite (which in my experience it can) then the role of
>>> testing in a 30K codebase is restricted even further to finding just 10
>>> defects. How well that expense can then be justified will vary from project
>>> to project, just as the defect count varies based on team experience, but I
>>> don't believe it's a priori demonstrable for all projects that a test suite
>>> is a desirable investment of developer effort.
>>>
>>> Fast-forward 2 years. You're working in another company and making big
>>> $$$. An bright but not-so-experienced programmer now has to work with legacy
>>> code (yours!), and he just hasn't had enough experience to be able to spot
>>> errors just by looking at other peoples' code.
>>>
>>> Now, wouldn't it be nice to have a documentation for this code in the
>>> form of a robust, explicit, "spelled-out" test suite? (Or worthy of
>>> investment?)
>>>
>>
>> Code isn't for computers, it's for people, and if it's not readable by
>> people it isn't fit for purpose. Therefore I'd rather a codebase written
>> with an engaging and legible style that I can sit down and read as hard copy
>> than a mountain of specs and tests. YMMV.
>>
>>
>> Ellie
>>
>> Eleanor McHugh
>> Games With Brains
>> http://slides.games-with-brains.net
>> ----
>> raise ArgumentError unless @reality.responds_to? :reason
>>
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20090220/2edceff7/attachment-0003.html>