From: "David A. Black" <dblack@...>
Date: 2008-08-04T03:23:22+09:00
Subject: Re: unit testing advice

Hi --

On Sun, 3 Aug 2008, Phlip wrote:

> David A. Black wrote:
>
>> It doesn't appeal to me not to use the model generator. For one thing,
>> I assume that it would mean having to run sequential migrations, where
>> you wrote a test or spec that tested for the presence of, say, a
>> first_name attribute on the user; then add that column to the
>> database; then test for last_name; then add that column; and so forth.
>> I don't mean to sound like I'm parodying what Steve is describing. I
>> assume that this, or something like it, is what you'd end up doing.
>
> Parenthetically, you are "allowed" to edit a pre-existing migration file, if 
> you can keep track of which VERSION your production database has.

Yes, but then you get into migrating backwards, which I increasingly
think is almost never appropriate. (Though not quite never, maybe.)

> Within that loop, yes, write a test that fails because MyModel has no 
> has_many NotherModel, then pass it by adding a column :nother_model_id to the 
> migration.

I'm afraid I don't see the advantage of that, at least in every case,
over bootstrapping at least part of a database schema and model
structure first. Certainly the kind of thing you're describing does
happen, but if I'm creating an Order model and I know that it's going
to belong to Customer, I'm not averse to saying so up front. Also,
with a large table, you could get into an awful lot of migrations.

It all comes out in the wash, so to speak, since once the project is
bootstrapped in some way, the different approaches to bootstrapping
tend to converge.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
  *  Advancing With Rails    August 18-21    Edison, NJ
  * Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!