Есть ли способ автоматически иметь "rake db: migrate RAILS_ENV = test" после "rake db: migrate" в среде разработки? - PullRequest
Новая
       22

Есть ли способ автоматически иметь "rake db: migrate RAILS_ENV = test" после "rake db: migrate" в среде разработки?

25 голосов
/ 03 августа 2011

Есть ли способ автоматически делать rake db:migrate RAILS_ENV=test после каждого rake db:migrate в среде разработки?

У меня есть guard и guard-rspec , и я действительно раздражен неудачными тестами, даже если он работает вручную в браузере.

Каждый раз, когда у меня возникала пауза в разработке, мне требуется не менее 15 минут, чтобы понять, что я просто забыл позвонить rake db:migrate:test после изменения базы данных.

Поскольку я уже использую guard , я подумал о добавлении guard-rake в проект, но я не знаю, какой файл мне смотреть. При просмотре development.sqlite3 , rake db:migrate RAILS_ENV=test будет запускаться каждый раз, когда я что-то делаю со своими записями через браузер, так что это не совсем то, что я хочу.

Может ли кто-нибудь помочь мне с моей проблемой?

Ответы [ 6 ]

18 голосов
/ 03 августа 2011

Возможно просто сделать псевдоним команды в вашем файле .bashrc.

~ / .bashrc 

alias rake_db_migrate='rake db:migrate db:test:prepare'

Terminal 

$ rake_db_migrate
3 голосов
/ 04 февраля 2015

Я использую этот псевдоним:
alias rake_db_migrate='rake db:migrate && rake db:migrate RAILS_ENV=test'

, поскольку rake db:test:prepare устарело.

Причина, по которой я это использую, заключается в том, что наш проект использует pg_search (postgreSQL) вместе со структурой.sql (не schema.rb) и по какой-то причине при запуске rake db:migrate не готовится тестовая база данных.

3 голосов
/ 21 мая 2013

Я предпочитаю использовать псевдоним следующим образом:

В вашем ~/.bashrc

alias migrate='rake db:migrate && rake db:test:prepare'

Легко потратить 30 минут, пытаясь понять, почему ваши тесты не проходят только для запоминанияВы не сбросили базу данных.Это решит эту проблему.

2 голосов
/ 12 июня 2014

Опция, которая мне очень нравится, это переопределить реальную задачу в другом скрипте rake.Это будет вызвано автоматически после запуска миграции.Таким образом, я всегда создаю диаграмму ERD после переноса базы данных: 

# lib/tasks/database.rake
namespace :db do
  desc 'Additional migrate task that creates the diagram'
  task :migrate do
    if Rails.env.development?
      Rake::Task['diagram:erd'].invoke
    end
  end
end

Так что в вашем случае: 

# lib/tasks/database.rake
namespace :db do
  desc 'Additional migrate task that creates the diagram'
  task :migrate do
    `rake db:migrate RAILS_ENV=test`
  end
end

Другой подход заключается в запуске следующего, который клонирует ваш новыйсхема к тестовой базе данных: 

rake db:migrate db:test:clone
2 голосов
/ 21 октября 2013

Быстрее: alias migrate='rake db:migrate db:test:prepare' (добавьте это в ваш .bashrc, он будет загружать Rails только один раз)

0 голосов
/ 08 октября 2013

В ответ на ваш первоначальный вопрос об использовании guard-rake вы можете посмотреть db/schema.rb, так как он будет обновляться при каждой миграции базы данных.Однако этот файл также будет изменен, если вы сделаете откат, поэтому вам, вероятно, придется извлечь версию миграции из строки определения схемы в db/schma.rb или использовать rake db:test:prepare вместо rake db:migrate RAILS_ENV=test.

* 1007.* Кажется, что это хрупко, поэтому использование псевдонима оболочки, вероятно, является лучшим подходом.Хотелось бы, чтобы был лучший способ!
...