He añadido la gema database_cleaner a mi aplicación de rieles para limpiar mi base de datos entre las especificaciones. Aquí está mi configuración actual para database_cleaner, ubicada enspec/spec_helper.rb:

  config.before(:suite) do
    DatabaseCleaner.strategy = :transaction
    DatabaseCleaner.clean_with(:truncation)
    DatabaseCleaner.start
    DatabaseCleaner.clean
  end

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

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

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

Ahora, esta configuración funciona bien, siempre y cuando cada última especificación que se ejecute pase o falle.

Sin embargo, en el caso de un error (rspec no le da una buena idea)E Como minitest, lanza este tipo de cosas:

09:17:32 - INFO - Running: spec
/usr/local/rvm/rubies/ruby-1.9.3-p392/lib/ruby/gems/1.9.1/gems/activerecord-4.0.1/lib/active_record/validations.rb:57:in `save!': Validation failed: Email has already been taken (ActiveRecord::RecordInvalid)

), la base de datos no se limpia! Los datos residuales de la especificación justo antes de que el error permanezca en la base de datos. Supongo que esto se debe a que database_cleaner no considera que la especificación errónea esté terminada y, por lo tanto, no limpia la base de datos.

Ahora, esto realmente no causa ningún daño hasta que vuelvas a ejecutar tus especificaciones. Los datos residuales causan un error análogo a esto:

09:17:32 - INFO - Running: spec
/usr/local/rvm/rubies/ruby-1.9.3-p392/lib/ruby/gems/1.9.1/gems/activerecord-4.0.1/lib/active_record/validations.rb:57:in `save!': Validation failed: Email has already been taken (ActiveRecord::RecordInvalid)

Eludir este error es bastante simple; corriendorails_env=test rake db:reset o la activación del shell de la base de datos y el vaciado de las tablas relevantes con sentencias de SQL borran estos datos y permiten que las especificaciones se ejecuten sin problemas.

Sin embargo, esto se está volviendo molesto. Un personaje incorrecto en cualquiera de mis especificaciones (cualquier cosa que lo haga erróneo en lugar de una falla) hace que todo mi flujo de trabajo de prueba se atasque, ¡casi como el mecanismo de disparo de un arma automática!

¿Cuáles son sus sugerencias con respecto a database_cleaner? ¿Tiene alguna configuración de ejemplo que permita limpiar la base de datos, incluso en el caso de una prueba errónea?

Estoy usando guardia para ejecutar mis rspecs que se aumentan aún más con factory-girl:

Gemfile:

source 'https://rubygems.org'

group :development do
    gem 'capistrano'
    gem 'rb-fsevent'
    gem 'debugger'
end

group :development, :test do
    gem 'rspec-rails', '~> 2.14.0'
    gem 'sqlite3'
    gem 'guard-rspec'
    gem 'guard-livereload', require: false
    gem 'guard-shell'
    gem 'webrick', '~> 1.3.1'
end

group :test do
    gem 'factory_girl_rails'
    gem 'capybara', '~> 2.2.0'
    gem 'selenium-webdriver'
#   capybara-webkit gem requires an application called 'libqtwebkit-dev' to build. To install 'libqtwebkit-dev' in Ubuntu, run
#   sudo apt-get install libqtwebkit-dev
#   gem 'capybara-webkit'
    gem 'rb-readline'
    gem 'launchy'
    gem 'database_cleaner'
end

group :production do
    gem 'pg'
#   gem 'puma'
end

# rails version
gem 'rails', '4.0.1'

# standard library
gem 'sass-rails', '~> 4.0.0'
gem 'uglifier', '>= 1.3.0'
gem 'coffee-rails', '~> 4.0.0'
gem 'jquery-rails'
gem 'turbolinks'
gem 'jbuilder', '~> 1.2'


group :doc do
  gem 'sdoc', require: false
end

# custom 
gem 'activeadmin', github: 'gregbell/active_admin'
gem 'devise'
gem 'simple_form'

spec / spec_helper:

# This file is copied to spec/ when you run 'rails generate rspec:install'
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'capybara/rspec'

# Requires supporting ruby files with custom matchers and macros, etc,
# in spec/support/ and its subdirectories.
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.check_pending! if defined?(ActiveRecord::Migration)

RSpec.configure do |config|
  config.include Capybara::DSL

  config.before(:suite) do
    DatabaseCleaner.strategy = :transaction
    DatabaseCleaner.clean_with(:truncation)
    DatabaseCleaner.start
    DatabaseCleaner.clean
  end

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

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

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

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

  # config.include RSpec::Rails::RequestExampleGroup, type: :feature

  # 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 = true

  # If true, the base class of anonymous controllers will be inferred
  # automatically. This will be the default behavior in future versions of
  # rspec-rails.
  config.infer_base_class_for_anonymous_controllers = false

  # Run specs in random order to surface order dependencies. If you find an
  # order dependency and want to debug it, you can fix the order by providing
  # the seed, which is printed after each run.
  #     --seed 1234
  config.order = "random"
end