Zalecałbym porzucenie testowej bazy danych, a następnie ponowne jej utworzenie i migrację:

bundle exec rake db:drop RAILS_ENV=test
bundle exec rake db:create RAILS_ENV=test
bundle exec rake db:schema:load RAILS_ENV=test

Po tych krokach możesz uruchomić swoje specyfikacje:

bundle exec rspec spec

Gerry3 zauważył, że:

Prostszym rozwiązaniem jest po prostu uruchomić rake db:test:prepare

Jeśli jednak używasz PostgreSQL to nie zadziała, ponieważ środowisko rails zostanie załadowane, co otworzy połączenie z bazą danych. Powoduje to, że wywołanie prepare nie powiedzie się, ponieważ DB nie może zostać upuszczone. Trudna sprawa.

Dostarczone rozwiązania wymagają załadunku środowiska szyn, co w większości przypadków nie jest pożądanym zachowaniem ze względu na bardzo duże obciążenie i bardzo niską prędkość. DatabaseCleaner gem jest również dość powolny, i dodaje kolejną zależność do aplikacji.

Po miesiącach niepokoju i irytacji z powodów vide supra, w końcu znalazłem następujące rozwiązanie, które jest dokładnie tym, czego potrzebuję. Jest ładny, prosty i szybki. W spec_helper.rb:

config.after :all do
  ActiveRecord::Base.subclasses.each(&:delete_all)
end

Najlepsze w tym jest to, że będzie tylko Wyczyść tabele, które skutecznie dotknąłeś (nietknięte modele nie zostaną załadowane i tym samym nie pojawią się w subclasses, również powód, dla którego to nie działa przed testami). Również, wykonuje po testach, więc (miejmy nadzieję) zielone kropki pojawią się od razu.

Jedynym minusem jest to, że jeśli masz brudną bazę danych przed uruchomieniem testów, nie zostanie ona wyczyszczona. Ale wątpię, że jest to poważny problem, ponieważ baza testowa zazwyczaj nie jest dotykana z testy zewnętrzne.

Edit

Ponieważ ta odpowiedź zyskała pewną popularność, chciałem ją edytować dla kompletności: jeśli chcesz wyczyścić wszystkie tabele, nawet te, które nie zostały dotknięte, powinieneś być w stanie zrobić coś takiego jak "hacki" poniżej.

Hack 1 - wstępne ładowanie wszystkich modeli dla metody subclasses

Oceń to przed wywołaniem subclasses:

Dir[Rails.root.join("app", "models", "**", "*.rb")].each(&method(:require))

Zauważ, że ta metoda może zająć trochę czasu!

Hack 2-ręczne obcinanie tabele

ActiveRecord::Base.connection.tables.keep_if{ |x| x != 'schema_migrations' }

Dostaniesz wszystkie nazwy tabel, z tymi możesz zrobić coś takiego:

case ActiveRecord::Base.configurations[Rails.env]["adapter"]
when /^mysql/, /^postgresql/
  ActiveRecord::Base.connection.execute("TRUNCATE #{table_name}")
when /^sqlite/
  ActiveRecord::Base.connection.execute("DELETE FROM #{table_name}")
  ActiveRecord::Base.connection.execute("DELETE FROM sqlite_sequence where name='#{table_name}'")
end

Wygląda na to, że w Rails 4.1+ najlepszym rozwiązaniem jest dodanie ActiveRecord::Migration.maintain_test_schema! do rails_helper po require 'rspec/rails'.

Https://relishapp.com/rspec/rspec-rails/docs/upgrade#pending-migration-checks

W aplikacji rails 4, Moje bin/setup jest zwykle rozszerzone o

puts "\n== Preparing test database =="
system "RAILS_ENV=test bin/rake db:setup"

Jest to bardzo podobne do odpowiedź Lewiatana, plus seeding test DB, jak

rake db:setup # Tworzenie bazy danych, ładowanie schematu i inicjalizacja za pomocą danych nasiennych
(użycie db:reset aby najpierw upuścić bazę danych)

Jak wspomniano w komentarzu, jeśli chcemy najpierw zrzucić DB, rake db:reset właśnie to robi.

Uważam również, że to dostarcza więcej informacji zwrotnych w porównaniu do rake db:test:prepare.