Allow processing jobs immediately in test mode about qu

[fbjork]

Can't wait to see some progress on this! Qu is great so far, but still needs some additional features to become awesome.

[bkeepers]

@fbjork Thanks, I hope to make some progress en route to RubyConf this week. Please do let me know what other features you think would make it awesome!

[luislavena]

Hello,

If I can comment, I think there are two approaches to this:

a in-memory backend that performs the enqueued job right away after enqueued,

Or, a kind of worker that do not trap signals or anything.

As example, for Resque we ended creating the following:

module Helpers
  def do_delayed_work!
    worker = SpecWorker.new('*')
    worker.work
  end
end

class SpecWorker < Resque::Worker
  def work(interval = 5, &block)
    while job = reserve
      working_on job
      perform(job, &block)
      done_working
    end
  end
end

Which is far from being pretty, but allowed us to execute the enqueued jobs.

Just my two cents.

BTW: great work on Qu, really loving it!

[bkeepers]

@luislavena great suggestions. You can use the existing worker to work off jobs in tests and it won't trap signals:

Qu::Worker.new('queue1', 'queue2').work_off

I was thinking I would implement test mode using hooks and work off the job after it is enqueued. I'm leaning toward this solution because it still goes through the whole stack and will make sure the args are serializable/deserializable.

[luislavena]

I was thinking I would implement test mode using hooks and work off the job after it is enqueued. I'm leaning toward this solution because it still goes through the whole stack and will make sure the args are serializable/deserializable.

Great approach, however there should be a way to control it. Under certain specs I would not like any job being performed.

Also, wouldn't Qu.enqueue and Qu::Worker.new(...).work_off exercise the args serialization?

[bkeepers]

Yep, enqueue and work_off would do it. That's how our tests for speakerdeck.com currently work.

On Sep 30, 2011, at 8:49 AM, Luis [email protected] wrote:

I was thinking I would implement test mode using hooks and work off the job after it is enqueued. I'm leaning toward this solution because it still goes through the whole stack and will make sure the args are serializable/deserializable.

Great approach, however there should be a way to control it. Under certain specs I would not like any job being performed.

Also, wouldn't Qu.enqueue and Qu::Worker.new(...).work_off exercise the args serialization?

Reply to this email directly or view it on GitHub:
#6 (comment)

[fbjork]

I suggest going with an in memory approach to avoid writing to Redis and adding jobs to the development queues. If not perhaps the jobs should be namespaced with the environment, i.e 'development-my_queue' or something along those lines.

[sumskyi]

how about https://gist.github.com/1391531 approach?

[bkeepers]

@sumskyi: looks like a good start to me. Want to submit a pull request with it?

[sumskyi]

@bkeepers: added #36

[bkeepers]

Awesome, thanks!