On 8/23/07, Ben Mabey <[EMAIL PROTECTED]> wrote: > David Chelimsky wrote: > > On 8/23/07, Ben Mabey <[EMAIL PROTECTED]> wrote: > > > >> Hey all, > >> I think I saw a thread about this earlier (maybe it was on the devlopers > >> list) but I am wondering if anyone has stubbed out AR so that the unit > >> test do not hit the database. The reason I am curious is because there > >> was a lightning talk given at the Ruby Hoedown (watch it here: > >> http://rubyhoedown2007.confreaks.com/session06.html) about separating > >> unit tests from the DB entirely and making it a lot faster. I'm not > >> just talking about not using fixtures but this would not even query the > >> DB for columns or do any inserts or updates either. Dan Manges was the > >> presenter and he talks about it on his blog and his newly released gem: > >> http://www.dcmanges.com/blog/rails-unit-record-test-without-the-database > >> > >> I haven't experimented with the gem yet but I'm sure it could be changed > >> to work with rspec. I'm curious about people's opinions about this > >> practice and see if anyone has done something similar with rspec > >> already. > >> > > > > I've heard of ppl experimenting w/ this but haven't seen it in action. > > I would LOVE to see this capability but I'd like to be able to control > > it from behaviour to behaviour. For example, I tend to mock all models > > in view, controller and helper specs, but not in model specs, where I > > tend to let them interact w/ the DB. I'm not recommending that > > approach over mocking models in model specs, just saying that it's my > > personal preference. There are very good arguments to do it > > differently. > > > > That said, I'd want to be able to do this in spec_helper.rb: > > > > Spec::Runner.configure do |config| > > config.deny_db_access :view, :controller, :helper > > end > > > > or _something_ like that. Then if a controller spec tries to hit the > > db you should get an error. > > > > Feel like contributing that? > > > > > So would the "config.deny_db_access :view, :controller, :helper" line just > throw an exception upon any DB access thereby acting as an alert saying that > your using the DB instead of mocking appropriately? Is that right? Or > should that line automatically stub the AR methods like new, save, create, > etc to prevent any DB activity but give the illusion of talking to the DB? > The latter is is what I was thinking for the model specs, although the alert > exception would also be a good idea- especially for the controllers, views, > and helpers. I have yet to dive into the rspec internals but I would > definitely like to contribute. Let me know if the alert idea is what you > meant. Thanks, > Ben > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
It should, imo, throw an exception when the DB is touched. Jay Fields posted about something like this a while ago: http://blog.jayfields.com/2006/06/ruby-on-rails-unit-tests.html 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. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
