I don't see anything wrong with using an observer, but like a rake task, don't fill it with code. Use it as an entry point into a plain old ruby class that you can easily test.
* Test the outcome of triggering the observer in an integration/acceptance test. * Unit test the plain old ruby class like you normally would. On 15/06/2012, at 8:26 AM, Andrew Harvey wrote: > Craig, > > I'm by no means an expert but I'm working on some different testing > strategies. I'd be interested to have a peek at railscamp. > > Andrew > > Sent on the run. > > On 15/06/2012, at 8:13, Craig Read <[email protected]> wrote: > >> Aleskey, >> >> I think that's a fairly simplistic view of Rails. >> Rails itself is made up of a lot more design patterns than Model, View and >> Controller. >> And I reckon you'd be hard pressed to put together any half-decent rails >> site only using those patterns. >> >> But as you implied, you need to use the right pattern for the right >> situation though. >> A service may be more appropriate for what I'm doing, but I'm not sure what >> benefits it would give me over the Observer in this situation. >> I'd still end up calling the service from callbacks in several different >> models whereas the one Observer can watch all those models and respond. >> >> Nicholas, >> >> The after_save callback is exactly what the Observer is doing. >> However, in this instance, I want to update 2 models with the cached results >> of a calculation involving data from those and other models. >> Rather than have the after_save in each model and increase coupling between >> them, I put it all in a single observer that can watch all those models. >> >> I'll have my laptop with the source at RailsCamp if anybody is keen enough >> to take a look and provide feedback. >> >> Cheers, >> >> Craig. >> >> On Mon, Jun 11, 2012 at 12:04 AM, Aleksey Gureiev <[email protected]> wrote: >> That's exactly what I do. Observers is a hack. Which part of MVC do they >> belong? Models? No. Controllers? No. And most definitely not views. I use >> observers in rare occasions when there's a cross-cut of some logic that >> doesn't belong to the business domain. For example, I would put some >> specific logging or reporting to GA there. Invalidating caches is another >> common choice. >> >> If you end up using observers to set flags, send notifications, or God >> forgive, initializing objects, think again. Most probably, you are looking >> for Factory or a Service. I would create a app/services/create_user.rb and >> stick all logic of instantiating new user records, calling notifiers and >> doing everything else that belongs to the user creating workflow there. It >> becomes (a) reusable, and (b) testable. >> >> - Aleksey >> >> >> On Saturday, June 9, 2012 3:49:12 PM UTC+3, marsbomber wrote: >> Testability is one of the reasons I try to keep myself away from observers >> or callbacks in general. >> >> What's wrong with introducing plain ruby classes that wrapping up all those >> callback logics? Explicit over magics, no? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/rails-oceania/-/_5a48BpKJ-oJ. >> >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> >> >> >> -- >> Craig Read >> >> @Catharz >> https://github.com/Catharz >> http://stackoverflow.com/users/158893/catharz >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. Cheers, Gareth Townsend http://www.garethtownsend.info -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
