Will Spurgin

Closing since we've added `#on` with v4

The failure description definitely needs some work. Under the hood, rspec-sidekiq uses a `ContainsExactly` so the following are _not_ the same expectations: ```ruby SomeJob.perform_async "some_arg", "some_other_arg" # expect a job...

A long time later but.... IMHO Doing any expectations around use of Time should involve freezing time. Sidekiq calculates the `"at"` context using `Time.now`, so there's gonna be natural differences...

Not that it's _exactly_ solving this use case but #200 would add support for the builtin argument matchers, so you could do something like: ```ruby expect(SomeJob).not_to have_enqueue_sidekiq_job(any_args) ``` It's a...

Piling on, with the new block syntax this works and is a little more intuitive. ```ruby expect { "do nothing" }.not_to enqueue_sidekiq_job ```

Just because there was _a long_ time between versions, I was aiming to _not_ disrupt existing projects and their use of the existing matchers. In future versions (since I'll be...

Believe this was fixed with https://github.com/wspurgin/rspec-sidekiq/commit/dcc6d037a2333a5af73ead81809b484fd0e9ac13 though it's not a direct comparison as a `to_int` is used to avoid fractional second mismatches.

I prefer the approach taken in #182 to line up with how Sidekiq calculates it. Same offer as over there. If you haven't moved on from Ruby/Sidekiq and `rspec-sidekiq`, feel...

Closing in favor of #194

A great idea IMO. I too ran across weird behavior from having batches mocked by default (#189). It's now been 8 (🙀) years since this PR, but I intend to...