On Friday, April 13, 2012 at 2:09 PM, Rodrigo Rosenfeld Rosas wrote: > Hello old friends, I'm getting back to Rails and Ruby programming full time > again (Yay!) > > I've stopped doing Rails programming to work with Grails in 2009 after 2 > years working with Rails due to a better job offer. > > Since then I've changed my job once more, but still on Grails, but I found a > critical bug in Grails more than a week ago that didn't seem to get much > attention and is affecting the production system I maintain: > > http://jira.grails.org/browse/GRAILS-8994 > > As I couldn't work around that bug and I can't see myself reading the Grails > source code (a real mess!) I decided to take another approach that would > allow me to get back to Rails programming. > > I created a Devise / Warden strategy to send the cookies to the current > system and it will return me the current logged in user. So I can set up > Nginx to proxy some requests affected by the Grails bug to this new Rails > application. > > I've finished this action last Monday but when I was about to send all the > hard work to the server lots of my directories were suddenly gone when I was > using them. I still don't know what happened but I've replaced my hard-drive > just in case, but it means I had to do all over again :( > > Anyway, now I got it back to work but testing a single action (an > update/insert one) will take about a full second to run using RSpec and > FactoryGirl. > > I really don't like Grails but they had a great feature for unit testing. > They were able to mock their domain class (that is how they call their > models) in such a way that they can perform most of the operations you can do > on real objects. > > Of course it have another serious bug that will prevent me to use it in lots > of cases: > > http://jira.grails.org/browse/GRAILS-8854 > > But the idea is great as it works seamlessly like in a memory database. > > So, I'd like to be able to keep my tests easy to read but avoid touching the > database that much. > > But my controller spec rely on lots of the setting of ActiveRecord for my > models, like maximum calculations in before callbacks, custom foreign keys > and depends: :delete_all in some has_many associations. Also I do also need a > user object that Devise will accept on its sign_in helper method. > > Is there any place I could read more about writing faster tests without > getting crazy writing so many mocks manually. For example, mocking a Grails > domain class in a unit test would be as easy as: > > @mock(User) > class UserTests... > > Then I'm able to do most operations using the Grails domain class API using > the User mock. > > Is there something like this for Rails and Rspec? Is there some way that I > could set up FactoryGirl to use those mocks instead of hitting the database > when I want to? > > Am I going in the wrong direction here? If so, what would be the right > direction? > > Thanks in advance. > > Glad to be part of the Ruby, Rails and Rspec community full-time again :D > > Cheers, > Rodrigo. You can use mock_model or stub_model to create model instances, or you can use FactoryGirl.build instead of FactoryGirl.create. Only mock_model will actually avoid db calls entirely (the others will still query for column names even if you don't save anything).
Those techniques, however, don't help you with finders. You still have to stub any finders with the object generated by any of the aforementioned techniques: thing = mock_model(Thing) Thing.stub(:domain_specific_finder => [thing]) It's not pretty, but it's the best way I know of to get what you're after. I started a lib called stubble a few years back that attempted to address this more holistically (https://github.com/dchelimsky/stubble) but I never released it as a gem because there were just too many different ways to access model data via the ActiveRecord API and they don't all flow through a single part of the codebase that we can override in an extension. HTH, David -- David Chelimsky Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users