I''m using rspec on a current rails project and one of the plugins I''m using (Paperclip) uploads file attachments for a model to S3. This obviously slows the tests down somewhat, and I would like to remove this altogether by stubbing -- the question is what should I be stubbing? Should I stub the upload method in the plugin class or do it in the model class? Any advice? Thanks, ~ Mark -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Mark Dodwell wrote:> I''m using rspec on a current rails project and one of the plugins I''m > using (Paperclip) uploads file attachments for a model to S3. This > obviously slows the tests down somewhat, and I would like to remove this > altogether by stubbing -- the question is what should I be stubbing? > > Should I stub the upload method in the plugin class or do it in the > model class?Whip out Mocha (or the other leading mocker), and stub the lowest call in your own code; the first call into the library code. (This is generic advice how to mock!) We do it like this: def toast_hit_real_server obj = assemble obj.activate # hits a server p obj.response end def test_hit_mock_server obj = assemble Paperclip.any_instance.expects(:upload).returns(:I_Likes) obj.activate # hits the mock assert{ obj.response == :I_Likes } end Write the first test, and when you run your test batch it hits the real server, and you can debug it and manually inspect the output. Then you "toast" the first test, and write the second test case to exactly match the first, with the mocker installed. Then we refactor the mocker into a reusable test method, such as mock_paperclip. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
This is Phlips area! Phlip did you pay him to ask this??? No real need to roll to Mocha, though, except for preference. rspec''s mocking capabilities are pretty similar (though I personally find it''s syntax much prettier). On May 16, 2:47 pm, Phlip <phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Mark Dodwell wrote: > > I''m using rspec on a current rails project and one of the plugins I''m > > using (Paperclip) uploads file attachments for a model to S3. This > > obviously slows the tests down somewhat, and I would like to remove this > > altogether by stubbing -- the question is what should I be stubbing? > > > Should I stub the upload method in the plugin class or do it in the > > model class? > > Whip out Mocha (or the other leading mocker), and stub the lowest call in your > own code; the first call into the library code. > > (This is generic advice how to mock!) > > We do it like this: > > def toast_hit_real_server > obj = assemble > obj.activate # hits a server > p obj.response > end > > def test_hit_mock_server > obj = assemble > Paperclip.any_instance.expects(:upload).returns(:I_Likes) > obj.activate # hits the mock > assert{ obj.response == :I_Likes } > end > > Write the first test, and when you run your test batch it hits the real server, > and you can debug it and manually inspect the output. > > Then you "toast" the first test, and write the second test case to exactly match > the first, with the mocker installed. > > Then we refactor the mocker into a reusable test method, such as mock_paperclip.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---