On Sat, Aug 2, 2008 at 5:17 PM, Shadowfirebird <shadowfirebird / gmail.com> wrote:
> On Sat, Aug 2, 2008 at 9:19 PM, marc <gmane / auxbuss.com> wrote:
>> David A. Black said...
>>> On Sun, 3 Aug 2008, James Britt wrote:
>>> > David A. Black wrote:
>>> >> In fact, one question that has come to intrigue me recently is the
>>> >> question of whether there are any active programmers who have
>>> >> literally written code test-first from the time they first learned how
>>> >> to program onward. I suspect the answer is no -- and if that's the
>>> >> case, it means that there is no evidence for the position that it's
>>> >> always, automatically bad to write code without a test.
>>> >
>>> >
>>> > Has anyone ever seen a Learn To Program or Learn Language Blub book that did
>>> > TDD?  I doubt such a thing exists.  Instead, people are shown code,
>>> > encouraged to write code, then (in so many words) told that what they were
>>> > shown and told is not the right way to code.   On the other hand, having  a
>>> > unit test for the 1-liner helloworld.rb seems massively goofy.
>>>
>>> The thing is, all the people who argue that testing first is the right
>>> way to code did not themselves learn to code that way. That doesn't
>>> prove or disprove anything, but it does make me wonder whether
>>> teaching someone test methodology right out of the starting gate is
>>> demonstrably the best way to go about teaching someone programming. I
>>> tend to think it isn't, though I also think that there are good and
>>> bad ways to introduce testing into the mix (the best way probably
>>> being to present it as essentially what they've been doing all along,
>>> but more structured; and the worst way being the "OK, the fun is over,
>>> now let's get serious" stuff).
>>
>> I started on coding sheets. We wrote tests first. We used to
>> "desk check" our code too. We had to, it might take a couple of days to
>> get the cards punched before getting one, perhaps two, compilations per
>> day. I'm in my forties, so this is ancient, but not prehistoric history.
>>
>> That said, I lean towards what David is saying, that it's a skill to be
>> learned after experimenting/playing with code. After all, we all learn
>> to speak before we write. And being able to write well takes a lot more
>> skill than simply being able to write what we say.
>>
>> --
>> Cheers,
>> Marc
>>
> I wish I had learned this stuff ten years ago.
>
> For almost my entire career people have assumed that I can look at
> their code and tell what it is supposed to do.  I can't; no-one can,
> with any accuracy.  All I can do is look at code and say what it
> *does*.  Which is probably not the same thing, or I wouldn't be
> looking at the code in the first place...
>
> But if there are automated tests, *they* will tell you what the code
> should do.  And, better yet, if the programmers have been using them,
> they will be accurate and up to date.  They might not be complete, of
> course, but two out of three is a hell of a good hit rate in this
> subject.
>
> As far as I am concerned, that's good enough to spark a religious conversion.
>
>
> As for test-driven-design, I think it's a fine ideal.  Mostly when I
> code I know in advance where I'm going, and in that case it pays to
> use TDD.   But sometimes I haven't the faintest idea what I'm doing; I
> don't know how many classes I need or what jobs go in what classes --
> or even if the idea is at all workable.  I suspect that TDD isn't of
> much use in those times.
>
Check out Test-Driven Development By Example by Kent Beck.  It brought
my understanding of TDD to a new level.

Regards,
Michael Guterl