Skip to content
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

Would love if have_queued was not so strict #121

Open
jchatel opened this issue Jan 20, 2016 · 1 comment
Open

Would love if have_queued was not so strict #121

jchatel opened this issue Jan 20, 2016 · 1 comment

Comments

@jchatel
Copy link

jchatel commented Jan 20, 2016

First of al, great gem, super useful, thanks for that.

I have a case where I test if a job can go on the queue or not with before_enqueue and this is the perfect gem for testing that.

That said, in my before_enqueue resque hook, I enrich my arguments.

For example, I create a database entry for error text/status I want to have associated with the job.

So, in the example, this fails:

expect(Person).to have_queued(person.id, :calculate)

Because I added another argument in the queue.

expect(Person).to have_queued(person.id, :calculate, :job_id => 123) would work, but I have no access to 123 since it's an auto increment.

Any suggestion to work around this? E.g. have_queued_at_least or have_gained_arguments, or have_queued_no_check_value...

Right now, I use Resque.peek to check the job and then do args validation. Making sure I do have a job_id, the number is irrelevant for me as much as testing my arguments have been enriched.

@leshill
Copy link
Owner

leshill commented Jan 25, 2016

Hi @jchatel,

Those sound like great additions. A PR would be greatly appreciated. Also please take note that in issue #119 @pboling is proposing a change to the way have_queued determines what to look at in the queue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants