On 8/24/07, Jim Deville <[EMAIL PROTECTED]> wrote: > > On Aug 23, 2007, at 9:48 PM, Pat Maddox wrote: > > > On 8/23/07, Jim Deville <[EMAIL PROTECTED]> wrote: > >>>>>> > >>> As far as model specs go...I've been toying with the idea of > >>> splitting > >>> up non-db-reliant behavior specs from the specs that do require the > >>> database. When you want to specify behavior you can just stub > >>> out the > >>> columns (because AR does try to hit the db to find the column info). > >>> Obviously for things where you need to hit the db, such as custom > >>> finders and such, you should use a real db. Kent Beck proposed > >>> writing a mock db interface that expects SQL queries but I > >>> thoroughly > >>> hate that idea. > >>> > >> > >> I'm wondering why custom finders need to hit the database? Mocking > >> out the columns method (as suggested by the articles) should work > >> just as well for custom finders as it would for AR finders. Am I > >> missing something? > >> > >> Jim > > > > If I've got something like > > > > def find_recent(limit = 5) > > find :all, :order => "created_at DESC", :limit => limit > > end > > > > I think it's better to just create 6 records and make sure it returns > > the proper 5. Then write another spec that only gets 3. > > > > I understand this, but overriding the Columns method, as suggested by > Fields and Manges, should take care of this without hitting the DB. > It's not checking the validity of the SQL, its using the columns > method to return your result from fixtures without hitting the DB.
I don't follow. How does it (and I'm not sure what it is, tbh) know how to return the proper fixtures in the proper order? You need an SQL engine to make it happen. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
