-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow processing jobs immediately in test mode #6
Comments
Can't wait to see some progress on this! Qu is great so far, but still needs some additional features to become awesome. |
@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! |
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! |
@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. |
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 |
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 Lavenareply@reply.github.com wrote:
|
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. |
how about https://gist.github.com/1391531 approach? |
@sumskyi: looks like a good start to me. Want to submit a pull request with it? |
Awesome, thanks! |
Instead of enqueueing a job, it should just be performed immediately.
The text was updated successfully, but these errors were encountered: