[LRUG] TDD (was: Ruby Contracting)

[Vahagn Hayrapetyan]

>
> 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/e429de0d/attachment.html>