I have a subapp that authenticates remotely, and pulls information from the main app using ActiveResource, and a token provided in a cookie, which sounds at least close to what you're trying to test
While it's possible to stub the values coming back, it can be tricky. By definition, you pretty much don't have access to the exact instance of a controller class, so stubbing controller.current_user just won't work ... plus, that exercises pretty much none of the authentication code. What I've taken too lately is making sure that my authentication code is really well separated, even from my ActiveResource model. at that point, in my integration tests, I drop a stub object into the authentication code, in place of the Active Resource, and my Givens set up return values for that stub object ... (stub in the it's a fake sense, not stub in the literal RSpec object sense) All that said, a couple of days ago, I caught wind of this little gem: http://fakeweb.rubyforge.org/ (and, of course, I can't remember who pointed it out ... might have been someone on this list, might have been someone on twitter ...) It looks like it cuts directly in front of the core HTTP library, and lets you register fake responses to the request. Using that, can probably just skip the above, and fake a response from the remote system ... acutally leaving the ActiveResource model in the system, and therefore, tested.... Just havn't had that chance yet On Tue, Apr 28, 2009 at 7:55 AM, doug livesey <biot...@gmail.com> wrote: > Further to this, here is what I am currently doing. > I installed the seed-fu plugin and wrote a method in my env.rb file like > this: > > # > # Load fixtures by tableised names. > # > def seed_fixtures( *fixtures ) > ActiveRecord::Base.establish_connection( > ActiveRecord::Base.configurations['test'] ) > ActiveRecord::Schema.verbose = false > > fixtures.each do |fixture| > load( File.join( RAILS_ROOT, "db/fixtures/test", "#{ fixture }.rb" ) ) > end > end > > So in any Given that requires my fixtures, I can call "seed_fixture > :my_first_models, :my_second_models" to load up anything I need for my > cucumber steps. > And the examle above called "seed_fixtures :users", and returned a user, > not just a true value. > > Cheers, > Doug. > > 2009/4/27 doug livesey <biot...@gmail.com> > >> Yeah, I take your point, but I would need to set that up with fixtures, >> wouldn't I? >> & really I guess I should be seeding the session with a User id & letting >> all of the code do its work, not just stubbing the find method on >> ActiveRecord. >> I'll have a think on it -- for the moment it's quick & uncomplicated, and >> I think that current_user returning true is fairly self-explanatory -- maybe >> returning :a_logged_in_user would be less evil. >> & my attitude there might have more to do with the time here being a >> half-hour off of midnight than conscientiousness! ;) >> Doug. >> >> 2009/4/27 Zach Dennis <zach.den...@gmail.com> >> >> On Mon, Apr 27, 2009 at 5:24 PM, doug livesey <biot...@gmail.com> wrote: >>> > Refactoring the current_user method a little, then stubbing the find >>> method >>> > in there did it. >>> > >>> > # ApplicationController >>> > def current_user >>> > User.find( session[:user_id] ) rescue nil >>> > end >>> > >>> > # Scenario step >>> > Given /^that a user is logged in to the session$/ do >>> > User.stub!( :find ).and_return( true ) >>> > end >>> >>> You probably want to return a User, no? Returning true is entirely >>> different than the normal find API w/ActiveRecord. It seems to be >>> misleading and I can see where it would cause problems where >>> controller or view code that relies on #current_user expects a User, >>> >>> >>> > >>> > Cheers, >>> > Doug. >>> > >>> > 2009/4/27 doug livesey <biot...@gmail.com> >>> >> >>> >> Except I'm now struggling with how it should work, sorry. >>> >> The step for the scenario looks like this: >>> >> >>> >> Given /^that a user is logged in to the session$/ do >>> >> controller.stub!( :current_user ).and_return( true ) >>> >> end >>> >> >>> >> However, when I try to puts the value of current_user as called from >>> the >>> >> ApplicationController#authorise method, it returns nil. >>> >> I've tried just stubbing out the authorise method, too, but that >>> doesn't >>> >> seem to work, either. >>> >> Am I approaching this the wrong way? >>> >> & cheers again, >>> >> Doug. >>> >> >>> >> 2009/4/27 doug livesey <biot...@gmail.com> >>> >>> >>> >>> & that nailed it, cheers man! >>> >>> Doug. >>> >>> >>> >>> 2009/4/27 doug livesey <biot...@gmail.com> >>> >>>> >>> >>>> > Please be sure to clip the relevant parts when responding - "all >>> of >>> >>>> > that" is only meaningful if I look at the other email in this >>> thread. >>> >>>> > Easy on my desk top. Not so easy on my phone. >>> >>>> >>> >>>> Bit too used to gmail threads, sorry! >>> >>>> Doug. >>> >>> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > rspec-users mailing list >>> > rspec-users@rubyforge.org >>> > http://rubyforge.org/mailman/listinfo/rspec-users >>> > >>> >>> >>> >>> -- >>> Zach Dennis >>> http://www.continuousthinking.com (personal) >>> http://www.mutuallyhuman.com (hire me) >>> @zachdennis (twitter) >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> >> > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- // anything worth taking seriously is worth making fun of // http://blog.devcaffeine.com/
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
