ruby on rails 4 - fake - database_cleaner está borrando mi base de datos de desarrollo
fake data rails (4)
Tengo database-cleaner
configurado para mi aplicación Rails 4, cada vez que ejecuto la prueba, descubro que mi base de datos se anula tanto en el entorno de test
como de development
.
Mis configuraciones están en rails_helper
como sigue:
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
¿Cómo puedo asegurarme de que el limpiador limpie el db en el test environment
sin tocar mi development
?
Mi database.yml
es el siguiente:
# 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''] %>
Bueno, no estoy seguro de lo que estaba haciendo mal, pero al deshacer todas las configuraciones que tenía para database_cleaner
:
- desinstalando la gema
database_cleaner
- eliminando todas las configuraciones relacionadas de ambos,
spec_helper
yrails_helper
Y luego seguir esta guía de Avdi Grimm , luego de reinstalar la database_cleaner gem
y también descomentar esta línea:
Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }
de mi rails_helper
, pude hacer que database_cleaner
vuelva a funcionar como se esperaba. Gracias a todos.
En mi caso, fue la conexión a la base de datos especificada en el archivo .env cuando utilicé dotenv-rails
gem. Por alguna razón, database_cleaner prefiere la conexión desde allí en lugar de la configuración de la aplicación Rails.
Si alguien está buscando otra fuente potencial de este problema, aleatoriamente tenía $DATABASE_URL
definido en mi archivo .bashrc
para apuntar directamente a mi base de datos de desarrollo. Me llevó unas horas encontrar eso.
Yo recomendaría cambiar
ENV["RAILS_ENV"] ||= ''test''
a
ENV["RAILS_ENV"] = ''test''
y eliminar
Rails.env = ''test''
como la variable de entorno RAILS_ENV debería ser suficiente para la configuración