David Masover wrote:

>> TDD seems badly suited to *really* rapid prototyping.

Confer "Architectural Spike". That means a prototype where your colleagues are 
the demonstration's audience. You should write enough of a new module to "close 
the loop". The new code will spike thru a view, middleware, back-end, a little 
productization, and a little testage. Y'all will then rewrite the spike via TDD.

However, if the prototype's audience is client-side, they might point here and 
there, and say, "okay, keep this here, but change that around. In one hour."

If they say that, you are already around the bend. The tests must already be in 
place to sustain the rate-of-change your client now expects of you. This is why, 
in some circles, the ideal is "there are no Prototypes!"

> I thought so, too. And I got quite a lot done, very fast, with this hobby 
> project I'm working on...
> 
> Then it reached a threshold -- not a very high one -- where I could no longer 
> reasonably develop the app, because of how long it was taking me to test it, 
> manually. At this point, I at least needed a testing framework.

Right. The bigger the project, the longer it runs, the more you need tests. They 
help you add new features faster than you added old ones. For example, at work, 
last year we added a bad database field that got stale very soon. Back then, the 
code was too fragile to just yank it out. But since then, we have relentlessly 
tested, and cleaned all around that variable, and today we took it out with no 
issues.

Under Brand X, the sooner you take that variable out, the less you suffer. The 
code will ossify around it.

-- 
   Phlip