Rspec allows expectations to be written using change(LogWorker.jobs,
:size). The result of .jobs in this case was a derived array that wasn't
manipulated under the covers. So when Rspec went to check the size of
the array after the fact, it appeared that nothing had changed.
This sets up a true array for the jobs for a single worker and
pulls jobs off that array so rspec can properly make assertions.
I have a lot of symbols in my code and so do others. This pull request
ensure that testing queus and jobs (just like production) are only ever
compared as strings.
When using the Sidekiq::Client API to push jobs on to the queue, it's
not ideal to assert the size of the queue from the perspective of a
worker because the worker may not exist in the application.
This API implements a testing API from the perspective of a queue. The
existing Worker-based testing API remains unchanged, but leverages the
job hash implemented through the Sidekiq::Queues class.
Examples:
assert_equal 1, Sidekiq::Queues["default"].size
assert_equal "SpecialWorker", Sidekiq::Queues["default"].first["class"]
Sidekiq::Queues["default"].clear
Sidekiq::Queues.clear_all
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