Mark Levison wrote:

>> - test the model in isolation from the controllers & view
>
> So you would Mock the controllers and the views in this case?

If you look up an MVC diagram, the Model only has inbound arrows. Or the
equivalent. To TDD the Model you simply ignore the controllers and views,
because MVC requires them to decouple.

>> - TDD new back-end features from the bottom up, not top-down
>
> Bottom up? How do you do that? Don't you normally Test Drive from the top
> down? Building only what you need along the way?

Anything the user can do to the Model thru the Views and Controllers, a unit
test can do the same way, bypassing them. Get a list, select an item, update it,
etc. So bottom-up should be just as good as top down.

Top-down is also part of TDD's algorithm generation concepts...

>> - abstract relationships, such as has-many, into accessors on records
>
> I'm even more confused. Hopefully the example will cover both.

In ActiveRecord:

class Order < ActiveRecord::Base
has_many :line_items
end

That's enough to find a table in the database called 'orders', find another
table called 'line_items', find their field 'order_id', and use it to populate
an array of LineItem model objects. The SQL is all hidden inside this, stretched
out among the declarations and conventions.

>> - test from a pool of example models ("fixtures") that mix-and-match
>> business rules
>
> Are you saying use sufficient sample data to exercise the paths through the
> business rules.

TDD will give you that. Rails makes it easy by letting you declare these pools
of records in your versioned source, _not_ in your database instance.

--
Phlip