database_cleaner is wiping my development database
Asked Answered
C

6

6

I have database-cleaner configured for my rails 4 application, Each time I run the test, I discovered that my database gets wiped out in both the test and development environment.

My configurations are in rails_helper as follow:

ENV["RAILS_ENV"] ||= 'test'
# This file is copied to spec/ when you run 'rails generate rspec:install'
require 'spec_helper'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'database_cleaner'
Rails.env = "test"
# Add additional requires below this line. Rails is not loaded until this point!

# Requires supporting ruby files with custom matchers and macros, etc, in
# spec/support/ and its subdirectories. Files matching `spec/**/*_spec.rb` are
# run as spec files by default. This means that files in spec/support that end
# in _spec.rb will both be required and run as specs, causing the specs to be
# run twice. It is recommended that you do not name files matching this glob to
# end with _spec.rb. You can configure this pattern with the --pattern
# option on the command line or in ~/.rspec, .rspec or `.rspec-local`.
#
# The following line is provided for convenience purposes. It has the downside
# of increasing the boot-up time by auto-requiring all files in the support
# directory. Alternatively, in the individual `*_spec.rb` files, manually
# require only the support files necessary.
#
# Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }

# Checks for pending migrations before tests are run.
# If you are not using ActiveRecord, you can remove this line.
ActiveRecord::Migration.maintain_test_schema!

RSpec.configure do |config|
  # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
  config.fixture_path = "#{::Rails.root}/spec/fixtures"

  # If you're not using ActiveRecord, or you'd prefer not to run each of your
  # examples within a transaction, remove the following line or assign false
  # instead of true.
  config.use_transactional_fixtures = false

  # RSpec Rails can automatically mix in different behaviours to your tests
  # based on their file location, for example enabling you to call `get` and
  # `post` in specs under `spec/controllers`.
  #
  # You can disable this behaviour by removing the line below, and instead
  # explicitly tag your specs with their type, e.g.:
  #
  #     RSpec.describe UsersController, :type => :controller do
  #       # ...
  #     end
  #
  # The different available types are documented in the features, such as in
  # https://relishapp.com/rspec/rspec-rails/docs
  config.infer_spec_type_from_file_location!

  config.before(:suite) do
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before(:each) do
    DatabaseCleaner.strategy = :transaction
  end

  config.before(:each, :js => true) do
    DatabaseCleaner.strategy = :truncation
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end


  config.mock_with :rspec

  config.before(:all) do
    ActiveRecord::Base.skip_callbacks = true
  end

  config.after(:all) do
    ActiveRecord::Base.skip_callbacks = false
  end

end

How can I ensure that the cleaner only wipes the db in test environment without touching my development?

My database.yml is as follow:

# PostgreSQL. Versions 8.2 and up are supported.
#
# Install the pg driver:
#   gem install pg
# On OS X with Homebrew:
#   gem install pg -- --with-pg-config=/usr/local/bin/pg_config
# On OS X with MacPorts:
#   gem install pg -- --with-pg-config=/opt/local/lib/postgresql84/bin/pg_config
# On Windows:
#   gem install pg
#       Choose the win32 build.
#       Install PostgreSQL and put its /bin directory on your path.
#
# Configure Using Gemfile
# gem 'pg'
#
default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see rails configuration guide
  # http://guides.rubyonrails.org/configuring.html#database-pooling
  pool: 5

development:
  <<: *default
  database: directory-service_development

  # The specified database role being used to connect to postgres.
  # To create additional roles in postgres see `$ createuser --help`.
  # When left blank, postgres will use the default role. This is
  # the same name as the operating system user that initialized the database.
  #username: directory-service

  # The password associated with the postgres role (username).
  #password:

  # Connect on a TCP socket. Omitted by default since the client uses a
  # domain socket that doesn't need configuration. Windows does not have
  # domain sockets, so uncomment these lines.
  #host: localhost

  # The TCP port the server listens on. Defaults to 5432.
  # If your server runs on a different port number, change accordingly.
  #port: 5432

  # Schema search path. The server defaults to $user,public
  #schema_search_path: myapp,sharedapp,public

  # Minimum log levels, in increasing order:
  #   debug5, debug4, debug3, debug2, debug1,
  #   log, notice, warning, error, fatal, and panic
  # Defaults to warning.
  #min_messages: notice

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  <<: *default
  database: directory-service_test

# As with config/secrets.yml, you never want to store sensitive information,
# like your database password, in your source code. If your source code is
# ever seen by anyone, they now have access to your database.
#
# Instead, provide the password as a unix environment variable when you boot
# the app. Read http://guides.rubyonrails.org/configuring.html#configuring-a-database
# for a full rundown on how to provide these environment variables in a
# production deployment.
#
# On Heroku and other platform providers, you may have a full connection URL
# available as an environment variable. For example:
#
#   DATABASE_URL="postgres://myuser:mypass@localhost/somedatabase"
#
# You can use this database configuration with:
#
#   production:
#     url: <%= ENV['DATABASE_URL'] %>
#
production:
  <<: *default
  database: directory-service_production
  username: directory-service
  password: <%= ENV['DIRECTORY-SERVICE_DATABASE_PASSWORD'] %>
Chesney answered 11/6, 2015 at 15:21 Comment(2)
What does your database.yml look like?Unfeigned
@SergioTulentsev I just edited the question to include the database.ymlChesney
C
0

Well, I'm not sure what I was doing wrong, but by undoing all the configurations I had for database_cleaner:

  1. uninstalling the database_cleaner gem
  2. removing all related configurations from both spec_helper and rails_helper

And then following this guide by Avdi Grimm, after re-installing the database_cleaner gem and also uncomment this line:

Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }

from my rails_helper, I was able to get the database_cleaner back to work as expected. Thank you all.

Chesney answered 12/6, 2015 at 4:9 Comment(0)
N
3

I'd recommend changing

ENV["RAILS_ENV"] ||= 'test'

to

ENV["RAILS_ENV"] = 'test'

and remove

Rails.env = 'test'

as the RAILS_ENV environment variable should be sufficient for configuration

Ne answered 11/6, 2015 at 15:28 Comment(4)
I tried this, but it did not work. the development env database still gets wiped out.Chesney
How do you include database_cleaner in your Gemfile? It should only reside in your test group: gem 'database_cleaner', group: :testNe
yes, @Ne it is included in the test group, alongside rspec-rails, capybara, factory_girl_rails, e.t.cChesney
This solved the same problem (dev't dbase being erased) when using vagrant, where I set RAILS_ENV in the environmentParse
V
2

If anyone is looking for another potential source of this issue, I randomly had $DATABASE_URL defined in my .bashrc file to point directly to my development database. Took me a few hours to find that.

Virgilvirgilia answered 27/6, 2017 at 16:24 Comment(0)
C
1

In my case it was database connection specified in .env file when I used dotenv-rails gem. For some reasons database_cleaner prefer connection from there instead of rails application config.

Concision answered 2/5, 2017 at 8:15 Comment(1)
I am using Docker and found the same thing. Running rspec from outside of Docker (Macbook) picked up the .env file and wiped my database. Renaming my .env to dev.env and updating docker-compose.yaml resolved this for me.Duckett
C
0

Well, I'm not sure what I was doing wrong, but by undoing all the configurations I had for database_cleaner:

  1. uninstalling the database_cleaner gem
  2. removing all related configurations from both spec_helper and rails_helper

And then following this guide by Avdi Grimm, after re-installing the database_cleaner gem and also uncomment this line:

Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }

from my rails_helper, I was able to get the database_cleaner back to work as expected. Thank you all.

Chesney answered 12/6, 2015 at 4:9 Comment(0)
B
0

I appreciate this is an old post but I had this issue today. I checked using pry and my ENV['RAILS_ENV'] = 'test' however my ENV['DATABASE_URL'] was set to my development db in the form of: postgres://localhost/my_dev_db

I added a line in the database cleaner config in rails_helper.rb to change to my test db like so:

  config.before(:suite) do
    ActiveRecord::Base.establish_connection(ENV['DATABASE_TEST'])
    DatabaseCleaner.clean_with(:truncation)
  end

where ENV['DATABASE_TEST'] was in the form of: postgres://localhost/my_test_db

This solved the issue for me.

Burnette answered 17/2, 2021 at 17:25 Comment(0)
C
0

For me the issue was having DatabaseCleaner.clean on the top level of rails_helper instead of within config.before(:suite).

Chromonema answered 12/1, 2022 at 18:39 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.