0

I'm using observers in my Rails app for notifications, activity feeds, etc. They keep my models and controllers clean, work great on the app side, and in any non-integration test (I've unit tested them extensively/successfully). But I can't for the life of me get them working in integration tests. I have the following in spec/support/observers.rb (as a sanity check. I'd ideally only enable them for feature tests if I can get them to work at all):

RSpec.configure do |config|
  config.before do
    ActiveRecord::Base.observers.enable :all
  end
end

No matter what I do, I can't get my observers to fire off during my integration tests (which is exactly what I really want to use to ensure that everything is truly working).

Does anyone have any insight on this or have any clue as to why I could be experiencing this? I'm using Rails 5.0.0beta3, and the latest versions of rails-observers, rspec-rails and capybara (from github master branches).

Greg Blass
  • 3,523
  • 29
  • 42
  • 1
    assuming you are using the master branch of rails-observer - what type of observers do you have? If you are using transactional fixtures - nothing that gets triggered after commit will ever fire. – Thomas Walpole Mar 14 '16 at 23:08
  • Hmm. I'm just declaring them like: class ModelObserver < ActiveRecord::Observer end – Greg Blass Mar 14 '16 at 23:37
  • 1
    but are they before_save, after_update, etc ? Also did you register them in your apps config `config.active_record.observers = :model_observer` – Thomas Walpole Mar 14 '16 at 23:42
  • I'm using before and after create, before and after update, and before and after save. I've got config.active_record.observers = [:this_observer, :that_observer] in application.rb – Greg Blass Mar 14 '16 at 23:44
  • 1
    Are you acutally using the Rails 5.0.0beta3 or are you using that from github master branch too? – Thomas Walpole Mar 15 '16 at 01:39
  • Neither seems to make a difference. – Greg Blass Mar 15 '16 at 03:07
  • 1
    There are currently some issues around the changes to rails autoloading where locks have been added for thread safety. I wonder if this may have something to do with that (It potentially comes into play with Capybara because Capybara runs the app in a second thread, and deadlocks can occur). If this issue doesn't occur with beta2 but does with beta3 it could be related - see https://github.com/rails/rails/issues/24094 , https://github.com/rails/rails/issues/23807 , https://github.com/rails/rails/issues/24028 – Thomas Walpole Mar 15 '16 at 16:57
  • Thank you @TomWalpole for all of your help. I need to move on so I'm refactoring my code to use concerns instead. – Greg Blass Mar 15 '16 at 17:07

1 Answers1

0

This isn't truly an answer to my question, but ain't nobody got time to wait around. No one cares about observers anymore because they were removed form Rails 4. There are next to no google topics related to them and capybara.

So, in order move on and get integration test coverage on the code I need, I'm refactoring my code to use concerns that include callbacks. This eliminates the observer dependency, and I was actually able to abstract my code even further this way since many of my observers were doing pretty much the same thing, and I had the core of what my observers were calling in service objects anyway.

Integration tests have no problem triggering these.

RIP Observers.

https://stackoverflow.com/a/18581715/2202674

Community
  • 1
  • 1
Greg Blass
  • 3,523
  • 29
  • 42