Inline testing currently overrides perform_async to simply directly call
SomeJob.new.perform(*args)
after round-tripping *args through JSON serialization/deserialization
and setting up a fake worker.jid value.
After Sidekiq issue 1938, most (all?) other places now use execute_job
instead, which indirectly calls SomeJob.new.perform(*args).
testing.rb defines a perform_one which is one of the places where the
new execute_job method is used. It also takes care of setting
worker.jid.
This change replaces the inline testing mode from a direct
SomeJob.new.perform method call to instead:
1. Place a job on the faked array queue, at the front of the list.
2. Immediately call perform_one, to take the job off the front of
the list.
This reduces the duplication around what it means to execute a job,
makes the usage of execute_job consistent across applications, and
improves inline testing's mirroring of how the job would actually be
run -- by "placing" it on a queue and then "pulling" the job off the
queue straight away.
As a bonus, any third-party gems which provide an implementation of
execute_job (such as in issue 1938) can test that their execute_job is
working by using perform_async with inline testing, instead of manually
calling perform_one in the fake testing mode or disabling Sidekiq
testing entirely.
In addition to requiring 'sidekiq/testing' and 'sidekiq/testing/inline',
a user can also call the following methods to control the test harness:
Sidekiq::Testing.fake!
Sidekiq::Testing.inline!
Sidekiq::Testing.disable!
Each of the above methods also accepts a block to execute within that
context before reverting to the state present before method invocation.
To query the current state, use the following methods:
Sidekiq::Testing.enabled?
Sidekiq::Testing.disabled?
Sidekiq::Testing.fake?
Sidekiq::Testing.inline?
Closes#1053
