comment tester les hooks de callback delayed_job en utilisant RSpec

Question

J'aimerais vérifier que les hooks de callback delayed_job sont bien appelés, mais je ne vois pas comment faire pour que RSpec le fasse, surtout lorsque plusieurs couches de classes sont impliquées.

Je suppose que j'ai un modèle ActiveRecord comme celui-ci :

class MyJob < ActiveRecord::Base
  def perform
    # do some stuff
  end
  def after(job)
    # called by delayed_job after perform completes
  end
end

Sur le plan conceptuel Je veux un test RSpec de ce type (même si je sais que ce n'est pas correct) :

it 'should call the :after callback hook' do
  my_job = MyJob.create
  my_job.should_receive(:after).with(an_instance_of(Delayed::Backend::ActiveRecord::Job))

  Delayed::Job.enqueue(my_job)
  Delayed::Worker.new.work_off
end

Je me suis penché sur stackoverflow, relishapp.com/rspec et tous les autres endroits auxquels je peux penser. Cela ne doit pas être trop difficile, n'est-ce pas ? (Je parie que @zetetic connaît la réponse dans son sommeil... ;)

(Avertissement : dans mon cas concret, j'utilise une classe "shim" entre MyJob et DJ. Une réponse à ce cas simple peut déclencher une suite plus complexe).

Answer 1

Ma suggestion serait de voir si la table Emplois crée un nouvel enregistrement d'emploi, puis d'introspecter les détails de cet enregistrement. J'ai déjà utilisé ce type de méthode dans le passé.

it "should sync content from the remote CMS" do      
  DelayedJobs::CMS::Sync.module_eval do
  def perform
    url.should == "http://example.com/tools/datafeed/resorts/all"
    Report.sync!([{'id' => 1, 'name' => 'resort foo'}])
  end
end

lambda do
  Report.sync_all!
end.should change(Delayed::Job, :count)

lambda do
  Delayed::Job.work_off
end.should change(Resort, :count).by(2)
end

Answer 2

Je ne pense pas que ce soit la meilleure chose à faire...

En faisant cela, vous essayez de spécifier le comportement de DelayedJob, pas votre application, et DJ a déjà sa propre série de tests.

Quoi qu'il en soit, qu'en est-il de l'imitation de DelayedJob lui-même ? Peut-être pouvez-vous spécifier, en faisant cela, que votre MockedJob appellera votre hook après le traitement, et vous pouvez créer vos matchers/attentes en conséquence...