Using ":until_executing, :until_executed, :until_timeout, :until_and_while_executing" all break Sidekiq::Testing

[jasonschock]

When I use any of the locks except :while_executing, I see this error when running tests:

Redis::CannotConnectError: Error connecting to Redis on 127.0.0.1:6379 (Errno::ECONNREFUSED)

It seems to suddenly be expecting Redis to be running. I could just start Redis locally, but for my CI server it's a problem. Any idea why these options might break Sidekiq::Testing?

In test_helper.rb:

...
require 'sidekiq/testing'
Sidekiq::Testing.fake!
require 'sidekiq_unique_jobs/testing'
...

Worker:

class MyWorker
  include Sidekiq::Worker
  sidekiq_options retry: 3
  sidekiq_options unique: :until_executed,
                  log_duplicate_payload: true

...

Test:

require 'test_helper'

classMyWorkerTest < ActiveSupport::TestCase
  test 'should do stuff' do
    assert_difference('MyWorker.jobs.size') do
      MyWorker.perform_async(12345)
    end
  end
end

[xtian]

I'm having the same issue.

[toadle]

Same here. Even though I test my workers with Worker.new.perform(args).

My wreck looks even bigger, when including require 'sidekiq_unique_jobs/testing' I immediately get:

/Users/tim/.rbenv/versions/2.2.3/gemsets/hopla/gems/sidekiq-unique-jobs-4.0.16/lib/sidekiq_unique_jobs/testing.rb:6:in `<class:Middleware>': undefined method `call' for class `SidekiqUniqueJobs::Client::Middleware' (NameError)

[mhenrixon]

For the sake of runtime performance and reliability the gem is now relying completely on lua. I'd suggest you look into running your tests using something like docker if having redis running is a problem. It doesn't make sense trying to replicate what the lua scripts do in memory. It caused the gem and testing it to be severely unreliable so I decided to drop the fake specific unique implementation and rely on the real deal instead.

[mhenrixon]

@toadle are you sure you have required the actual gem before the test overrides? Seems like the gem has not been required.

[toadle]

@mhenrixon I was pretty sure I had this wired correctly, but I'll try it again.

Also: Isn't it possible to at least disable sidekiq-unique-jobs in Testing-Mode completely? I mean in testing the uniqueness isn't that big of a deal as in production mode.

I'm with @jasonschock that the redis-dependency is also extremely difficult to cope with, when using a CI-server. In my case I had to completely get rid of sidekiq-unique-jobs in order to get it running again.

[jasonschock]

@mhenrixon As @toadle mentions, I think just having an option to disable the gem when running tests would be a simple solution. I'm not super worried about testing uniqueness either, but I at least want to:

• use the gem
• have my other tests not break 😃

If I were someone worried about testing uniqueness, then I would probably be someone that would also go through the effort of running Docker or some such so as to have a real instance of Redis running. (That's not me.)

Maybe a block helper, like Sidekiq uses?

SidekiqUniqueJobs::Testing.disable! do

...

end

[mhenrixon]

Why don't you just remove the middleware when you are testing? I mean if you really don't care then just remove the middleware.

[pcai]

Thanks Mikael for the awesome gem. I figured I'd contribute the exact code required, since we just hit this issue ourselves in our test environment:

Sidekiq.configure_client do |config|
  config.client_middleware do |chain|
    chain.remove SidekiqUniqueJobs::Client::Middleware
  end
end

[brunomperes]

@pcai where exactly does your snippet go? I've tried on spec_helper but the error persists

[mhenrixon]

https://github.com/mhenrixon/sidekiq-unique-jobs/releases/tag/v4.0.18

[ragesoss]

That snippet worked for me: WikiEducationFoundation/WikiEduDashboard@06b8e52