Re: How to ducktype a Hash?

On Sunday 06 June 2004 18:38, Bill Kelly wrote:
>
> Or maybe you're like me and can write software with a low
> defect rate without automated testing.  I used to do a
> bang up job with just ASSERT() macros in C.

I tend to have a low defect rate these days.  Not that they don't happen, it's 
just that I tend to be careful in areas I know are troublesome and I get rid 
of the big problems very early.  Some things still get me, but nothing I can 
anticipate, and virtually never something that comes back and gets me a 
second time on the same project.  I've been programming for something like 23 
years now.  I started with Basic on the TRS-80 and did a lot of ASM-like 
programming using Peek and Poke.  My first real programming class was in 
1982, Cobol, time-sharing an HP.  Perhaps I just approach programming in a 
way now that solves a lot of problems, and a lot of younger programmers 
haven't figured it all out yet and unit tests get them to a higher quality of 
code quicker.

> But what I get out of code developed test-first is extreme
> flexibility.  Test-first development is hard for me, I
> feel like I'm going slower in the short term, all the time.
> But I notice the my flexibility to tear up the program and
> reconfigure it to develop new features requested by the
> customer incrementally, and redesign old parts of the program
> when they are no longer adequate to accommodate new features,
> is significantly improved by having a unit-test network
> supporting my refactoring.  It also, I find, boosts my
> confidence in releasing frequently to users, or to a live
> server environment, while development is underway of new
> features, without having some lengthy "code lockdown" testing
> phase bug fixing phase before putting out a new release.  Which
> is important to me.

This is a kind of testing that pre-dates the unit testing craze.  You're 
talking about testing project components.  I've always done that.  In 
sufficiently large projects, when it's nearly impossible to bring up a fully 
functional system for testing, you have no choice but to create test robots 
that work your interfaces.  The idea is, if the tests can do it, the 
production code should be able to do it.  In this way, you can tear out and 
flush code right down the toilet if you want to and start from scratch 
wearing a bikini and combat boots, and if the test robot can do it, it's 
ready for production.

> Correct me if I'm wrong, but it sounds like you've tried
> Unit testing, but not test-first development.  Sporadically?

I've used test-first and unit tests in several projects, and developed my own 
testing framework for Ruby.  The framework had two distinct advantages over 
the unit testing I tried that I think ships with Ruby.  One, you can control 
the order in which your tests execute.  The built-in unit testing calls 
methods in an arbitrary order.  The other advantage is, it spits out all of 
it's results, including captured STDOUT and STDERR output, and reports it all 
as a nice YAML document.

All I mean is, I took it VERY seriously for awhile.  A lot of people seem to 
feel that if you don't like unit tests, you must be new to them.  I'm not new 
to them, I just don't find them helpful.

> So that leads me to wonder if refactoring is less of an
> issue for you, or unit tests didn't help you refactor
> more easily?  Or whatever, something is making your
> experience with unit tests different from mine.

I refactor constantly.  We always called it, "cleaning up the code" and/or 
"modularizing the code."  I used to feel really guilty for doing it on 
certain projects.  I'm glad someone coined the phrase "refactoring" and made 
it cool; now when I say I'm "refactoring" people smile widely, instead of 
looking at me sternly and asking me why I would fool with working code.

> But - if so I'm interested.  I hope that our experiences
> being different doesn't automatically imply fanaticism
> on my part.

Nope, I just think that unit tests are for certain kinds of programmers.  If 
it helps you, that's great.  It slows me down.  I return to them all the 
time, because until people shut up about them, I think perhaps there's 
something to it I'm missing.  But I always find that when I do return to 
them, I stop being "the productive programmer" and start being "the prissy 
flailing slow programmer."  I like being fast and good and lot better than 
slow and prissy.

	Sean O'Dell