Skip to content

have_enqueued_sidekiq_job without argument default behavior

Will Spurgin edited this page May 15, 2024 · 4 revisions

This change has been released with v5.0.0

If you're on version >= 5 of this gem, there's nothing for you to do. Feel free to go about the rest of your day!

Otherwise (or if you're just curious), read on.

What's changing with v5?

The choice has been made to treat have_enqueued_sidekiq_job without arguments as more permissive so that we're more inline with the general patterns of other builtins (e.g., raise_error) and other similar libraries (like rspec-rails). The default will be to use any_args if you do not provide expected arguments.

# Versions >= 5.x

have_enqueued_sidekiq_job == have_enqueued_sidekiq_job(any_args)

Silence warnings

If you were relying on the previous behavior before v5, you'll want to provide no_args to the matcher. Doing so will drop the warning for the given usage.

# if you need to maintain legacy behavior
expect(AwesomeJob).to have_enqueued_sidekiq_job(no_args)

Optional: ignore and silence all warnings (if any remain)

After reviewing you tests to ensure you're comfortable with the upcoming new behavior, you can silence any remaining warnings entirely with:

RSpec::Sidekiq.configure do |config|
  config.silence_warning(:have_enqueued_sidekiq_job_default)
end

Context

In the first few major versions of this gem, the behavior of using have_enqueued_sidekiq_job without any arguments was equivalent to explicitly expecting no arguments were expected when enqueuing the given Sidekiq job.

# Versions <= 4.x

have_enqueued_sidekiq_job == have_enqueued_sidekiq_job(no_args)

In an effort to be more inline with the general patterns of other builtins (e.g., raise_error) and other similar libraries (like rspec-rails), the default going forward will be to use any_args.

# Versions >= 5.x

have_enqueued_sidekiq_job == have_enqueued_sidekiq_job(any_args)