Rails Observers - когда и когда не использовать наблюдателей в Rails

Я чувствую, что наблюдатели получают плохой рэп во многом потому, что люди объединяют их с обратными вызовами жизненного цикла ActiveRecord как одно и то же. Я согласен со многими популярными мнениями о том, что обратные вызовы жизненного цикла легко злоупотреблять, запутывая себя, но я лично большой поклонник наблюдателей за то, чтобы держать вещи вне классов моделей, которые не являются основной ответственностью конкретной модели. Вот подсказка: наблюдатели Rails были частично вдохновлены аспектно-ориентированным программированием - они о сквозных проблемах. Если вы вкладываете бизнес-логику в наблюдателей, которые тесно связаны с моделями, которые они наблюдают, вы делаете это неправильно IMO.

они идеально подходят для хранения беспорядка из классов моделей, таких как срок действия кэша (sweepers), уведомления различных видов, обновления потока активности, запуск фоновых заданий для отслеживания пользовательских событий аналитики, теплых кэшей и т. д.

Я категорически не согласен с BlueFish о наблюдателях трудно правильно модульный тест. Это именно самый большой момент, который отличает их от обратных вызовов жизненного цикла: вы можете тестировать наблюдателей изолированно, и это не позволяет вам попадать во многие из тяжелых для государства и порядка ловушек дизайна, на которые ссылается BlueFish (что опять же, я думаю, чаще верно для обратных вызовов жизненного цикла).

вот мой рецепт:

1. по умолчанию отключите всех наблюдателей в наборе тестов. Они не должны усложнять ваши тесты модели, потому что они должны иметь отдельные проблемы в любом случае. Вам не нужно модульный тест, который наблюдатели фактически запускают, потому что набор тестов ActiveRecord делает это, и ваши интеграционные тесты будут охватывать его. Используйте блочную форму ActiveRecord::Base.observers.enable Если вы действительно верьте, что есть веская причина, чтобы включить наблюдателя для какой-то небольшой части ваших модульных тестов, но это, вероятно, показатель неправильного использования или проблемы с дизайном.
2. включить наблюдателей для интеграции только тесты. Интеграционные тесты, конечно, должны быть полными стеками, и вы должны проверять поведение наблюдателя в них, как и все остальное.
3. Unit-Проверьте свои классы наблюдателей в изоляции (вызывать методы, как after_create напрямую). Если наблюдатель не является частью бизнес-логики своей наблюдаемой модели, он, вероятно, не будет сильно зависеть от деталей состояния экземпляра модели и не потребует большой настройки теста. Вы можете часто издеваться над сотрудниками здесь если вы достаточно уверены, что ваши интеграционные тесты охватывают то, что вас больше всего волнует.

вот мой стандартный spec/support/observers.rb для приложений, использующих RSpec:

RSpec.configure do |config|
  # Assure we're testing models in isolation from Observer behavior. Enable
  # them explicitly in a block if you need to integrate against an Observer --
  # see the documentation for {ActiveModel::ObserverArray}.
  config.before do
    ActiveRecord::Base.observers.disable :all
  end

  # Integration tests are full-stack, lack of isolation is by design.
  config.before(type: :feature) do
    ActiveRecord::Base.observers.enable :all
  end
end

и вот пример это, я надеюсь, иллюстрирует хороший случай для использования наблюдателя и тестирования его без боли.