Configure ActiveJob's queue adapter to DelayedJob #526
Conversation
| config.active_job.queue_adapter = :delayed_job | ||
| RUBY | ||
|
|
||
| inject_into_class 'config/application.rb', 'Application', config |
There was a problem hiding this comment.
Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
This removes the step to manually configure the `ActiveJob`'s adapter. Closes #520
|
This seems good to me, anyone have any thoughts? |
|
👍 from me. @mcmire do we have any delayed job specifics in other parts of the project? See Derek's comment: #520 (comment) |
|
That's a good question. I don't know as I haven't studied the Suspenders code in a long time. |
|
Looping in @derekprior for that. Next week I'll test and merge! |
|
Thank you for the fast feedback guys. What about this piece of code? https://github.com/thoughtbot/suspenders/blob/master/templates/background_jobs_rspec.rb I think I need to look more into |
|
Another option would be to use the inline adapter when running features which will execute the jobs immediately. Any thoughts are welcome! |
I think this would have the same effect as the current |
I agree. I'm just wondering here... is there any reason to make it only for integration tests and not for the whole test environment? |
I think the theory is: In integration tests, we assume that you generally want to test everything working together, so it makes sense to just run the background jobs and treat the fact that they're backgrounded as an implementation detail. When your test is "the credit card is charged," you don't care if that happens in an HTTP request or a background job. In unit tests, we assume that you're testing a specific class, and any interactions with other classes are managed by the test. That means that you probably don't need the actual background job to run; you just need to verify that it did run. We usually use mocks to verify this. In reality, tests tend to be at least somewhat of a blend of both, but this default approach to testing background jobs seems to be reasonably intuitive and has worked out well for us so far. |
I know. That's why I asked whether is worthy to set this only for the integration tests. We would anyway mock the background jobs in the unit tests and I couldn't think of a reason not to set the Don't take me wrong. I don't mind just to change the existing test helper if that's what we want. |
Ah, I see. I misunderstood your original question. I'd be open to trying |
* Use `:inline` queue adapter in test environment to execute the background jobs immediately * Remove the background jobs template because it's not necessary anymore
|
Any thoughts? |
|
This looks good to me. @tute any thoughts? |
| configure_application_file( | ||
| "config.active_job.queue_adapter = :delayed_job" | ||
| ) | ||
| configure_environment "test", "config.active_job.queue_adapter = :inline" |
|
This looks good to me! I didn't know about |
|
@jessieay I'm glad that you find my PR is useful. |
|
Merged in fce1401. Thank you! :) |
This removes the step to manually configure the
ActiveJob's adapter.Closes #520