️ Sidekiq Dinner Party: Why Inline Brings Everyone (and Drain Doesn’t)

By Deepan Kumar

Sometimes in Rails, the tiniest change feels like pulling the fire alarm 🚨. One innocent update and suddenly every Sidekiq job in the city wants to party.

product.update(name: 'New Name')

Seems harmless, right? Just a tiny save.

But in your Rails app, that update can trigger multiple Sidekiq jobs behind the scenes:

Notify the team
Update the search index
Recalculate analytics
…and maybe more

Now you want to write a test. But here’s the catch: you only care about the result of one specific job. This is where Inline! and Drain behave very differently.

Inline! — Runs Everything, Instantly 🏃‍♂️💨

Sidekiq::Testing.inline! do
  product.update(name: 'New Name')
end

product.update runs
All after_update callbacks fire
Every job triggered by those callbacks runs immediately, including nested jobs

Output:

NotifyTeamWorker executed
SearchIndexWorker executed
MetricsWorker executed

Inline is like inviting everyone on the street to your party, because the actual guest you care about happens to live on that street.

✅ Your job runs as expected

❌ But you also get all the extra jobs running as side effects

Inline itself isn’t “wrong.” It’s just too eager when your test needs focus.

Drain — Focus on What Matters 🎯

By default, in Rails tests, jobs are queued and do not run automatically. This allows you to pick exactly which job to test:

product.update(name: 'New Name')

# Inspect jobs
expect(NotifyTeamWorker.jobs.size).to eq(1)
expect(SearchIndexWorker.jobs.size).to eq(1)
expect(MetricsWorker.jobs.size).to eq(1)

# Only run the job you care about
SearchIndexWorker.drain

Output:

SearchIndexWorker executed

Drain is like a careful party planner: all the invitees are on the list, but you let only the VIPs in — in this case, the job you actually care about.

✅ More focused test

✅ Reduces noise — you’re not dragged into testing side effects of unrelated jobs.

✅ Faster RSpec runtime — because you’re not executing a whole chain of jobs that your test doesn’t care about.

Moral of the Story

Inline! isn’t inherently wrong, but it becomes problematic when your goal is to test a single job.
Drain lets you focus, giving you control and avoiding side effects from other jobs triggered by the same action.

Think of it like hosting a party:

Inline: you invite everyone on the street because your actual guest lives there 🎉
Drain: you invite only your actual guests🍹

So the next time your tests feel noisy, bloated, or slow — maybe it’s because you’ve been inviting the whole street when you just needed one guest.