inline doesnt work for RSpec

[brentgreeff]

solid_queue (1.1.3) & rails 8.0.1.

I had config.active_job.queue_adapter = :solid_queue set for config/environments/test.rb
but this meant that job code was not executed inside tests.

By that I mean - I have request specs - which peform_later - but my job code is then not exercised by the test.

I changed to config.active_job.queue_adapter = :inline which means my jobs are executed in tests - which is what I want, but then if I use:

.set(wait: 30.minutes).perform_later(self.id)

expected no Exception, got #<NotImplementedError: Use a queueing backend to enqueue jobs in the future.

This is annoying.
I was using good_job before this for 3 years and I dont remember an issue like this.

Is it my imagination or did DHH say something about preferring integration testing?
That its better to test behaviour broadly, instead of little islands of functionality.
I also use capybara-email gem for system_specs. - I haven't tried it with solidQ yet, but that would be a deal-breaker if I cant get it working.

[rosa]

Hey @brentgreeff, Solid Queue doesn't support the test environment out of the box. Rails, however, includes a test adapter (ActiveJob::QueueAdapters::TestAdapter) that supports running jobs in test, asserting about which jobs are enqueued and with which arguments (including delayed jobs), and all the like. The inline adapter doesn't support scheduling jobs in the future. You can read more about this here. The test adapter is the default in test, you don't need to set it.

[brentgreeff]

Thanks @rosa but I understand all of that.

How it should work is that

.set(wait: 30.minutes).perform_later(self.id) - should be translated to .perform_later(self.id) in tests - ie the wait should be removed. Since no-one would want to wait in a test.

"asserting about which jobs are enqueued and with which arguments" - this is exactly the opposite of a "behavioural" test - thats a unit-test.

I will simply have to add if Rails.env.test? to all my calls where I am using wait.

"Solid Queue doesn't support the test environment" - thats exactly the problem - it should - testing is fundamental to rails development.

[rosa]

Hey @brentgreeff, understood, but if you want a job scheduled in the future to run immediately in your tests, you're also not testing the real behaviour.

"asserting about which jobs are enqueued and with which arguments" - this is exactly the opposite of a "behavioural" test - thats a unit-test.

Not really, because you'd also perform the jobs. This helps you with things like the scheduled time, which you wouldn't be able to test in any other way since you can't wait 30 minutes in your test. Then, you can also make sure the jobs are executed as they would in production, and also ensure the scheduled time is the one you expect.

"Solid Queue doesn't support the test environment" - thats exactly the problem - it should - testing is fundamental to rails development.

Rails has a test adapter precisely for this.

[brentgreeff]

Testing the schedule time - is not behavioural testing.

That is testing a configuration detail.

Why on earth would someone write a test for that - its pedantic.

I already have a solution - thank you.

[rosa]

Why on earth would someone write a test for that - its pedantic.

You probably wouldn't write it for wait: 30.minutes, but it'd be helpful to write it if the delay time depended on some more complex logic.

[brentgreeff]

You are still talking about unit tests.
I have clearly and repeatedly said - I am not talking about unit tests.

[rosa]

I'm not talking about unit tests, either. You can both make assertions about how the job was enqueued and also perform the job using Rails's test adapter, as I said above and as the documentation I linked showed, allowing for end-to-end testing. This would work in any kind of test, unit and also integration or system.

In any case, this discussion is irrelevant and unproductive 🤷‍♀