Quantcast
Channel: Active questions tagged redis+ruby-on-rails - Stack Overflow
Viewing all articles
Browse latest Browse all 873

What's the Ruby RSpec best practice for dealing with background jobs and am I doing something needlessly complicated?

$
0
0

I'm not sure if I have a bug somewhere, or am just not using good practice. Suppose I have either of the following:

class ThingMailer < ApplicationMailer
  def notify_of_thing
    mail(subject: 'Thing has happened')
  end
end

# ... and elsewhere...

class ThingDoer
  def do_thing
    ThingMailer.notify_of_thing.deliver_later(wait: 30.seconds)
  end
end

or

class ThingWorker
  include Sidekiq::Worker

  def perform(name)
    some_model.update(name: name)
  end
end

# ... and elsewhere...

class ThingPerformer
  def perform_thing
    ThingWorker.perform_in(30.seconds, 'Bob')
  end
end

And elsewhere I have a feature test (or other highish level test) which, in the normal course of things, causes ThingPerformer#perform_thing or ThingDoer#do_thing to be called. What's the best practice for dealing with them in a test suite?

In my actual test suite, if I don't just stub out one of the thread-launching methods, and if I'm not running Redis in the background while the tests run, I get the error Error connecting to Redis on 127.0.0.1:6379 (Errno::ECONNREFUSED) (Redis::CannotConnectError).

In config/environments/production.rb, we specify the cache store:

config.cache_store = :redis_store, ENV['REDIS_URL'], { expires_in: 90.minutes }

But our config/environments/test.rb, we specify that the app shouldn't perform caching (though presumably that's not working, and maybe just fixing whatever's causing this issue would be the answer to the first question?)

Here's the test.rb file:

Rails.application.configure do
  # Settings specified here will take precedence over those in config/application.rb.

  # The test environment is used exclusively to run your application's
  # test suite. You never need to work with it otherwise. Remember that
  # your test database is "scratch space" for the test suite and is wiped
  # and recreated between test runs. Don't rely on the data there!
  config.cache_classes = true

  # Do not eager load code on boot. This avoids loading your whole application
  # just for the purpose of running a single test. If you are using a tool that
  # preloads Rails for running tests, you may have to set it to true.
  config.eager_load = false

  # Configure public file server for tests with Cache-Control for performance.
  config.public_file_server.enabled = true
  config.public_file_server.headers = {
    'Cache-Control' => 'public, max-age=3600'
  }

  # Show full error reports and disable caching.
  config.consider_all_requests_local       = true
  config.action_controller.perform_caching = false

  # Raise exceptions instead of rendering exception templates.
  config.action_dispatch.show_exceptions = false

  # Disable request forgery protection in test environment.
  config.action_controller.allow_forgery_protection = false
  config.action_mailer.perform_caching = false

  # Tell Action Mailer not to deliver emails to the real world.
  # The :test delivery method accumulates sent emails in the
  # ActionMailer::Base.deliveries array.
  config.action_mailer.delivery_method = :test
  # config.active_job.queue_adapter = :test

  # Fix the order in which test cases are executed.
  # config.active_support.test_order = :sorted

  # Print deprecation notices to the stderr.
  config.active_support.deprecation = :stderr

  # Raises error for missing translations
  config.action_view.raise_on_missing_translations = true

  config.cache_store = :null_store
end

Viewing all articles
Browse latest Browse all 873

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>