On Tue, Nov 4, 2008 at 2:54 PM, Ashley Moran <[EMAIL PROTECTED]>wrote:
> > On Nov 04, 2008, at 10:15 pm, Mark Wilden wrote: > > I think it's actually simpler to do 'rake db:test:prepare' rather than >> migrate the test database. Migrations can be a pain when you've only got one >> database to worry about, much less two. The db:test:prepare task extracts >> the schema from the development database, drops the test database, then >> builds it again with the schema script. One reason I like it is that I know >> for sure that my tests are starting from a known state - empty. The other is >> that I know for sure that the test db matches the dev db. >> > > Except, this doesn't work if your migrations contain seed data, eg lookup > tables. In which case you have to compensate for this in your spec setups, > which is a risky DRY violation. It's safer to get your test db into shape > the same way you get your production one. > See my response in the other thread. :) I can imagine situations in which none of the solutions I offered would apply, but if possible I would prefer them over depending on the contents of the test database. We had a similar situation at work, where we thought we needed certain data in order to test. We had all kinds of problems keeping test and development in sync (both schema and data). A closer look showed that that data was not in fact necessary. I'm not saying that applies in all cases, of course. ///ark
_______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
