I had a crazy idea today based off a reader''s question[1]. Why are rake db:migrate and rake db:test:prepare two different tasks? Why can''t we have rake db:migrate migrate both the development and the test database at the same time? So many noobs (I''ll include myself in that basket too) get tripped up on this. How many times have you ran into it? From what I can see, there is no reason at all why the development and test databases should be different. What would you think about having these as one task in Rails 3.0.1 or Rails 3.1, with obviously a deprecation warning for rake db:test:prepare or something? [1] http://www.manning-sandbox.com/thread.jspa?threadID=39618&tstart=0 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Sep 21, 2010 at 11:51 AM, Ryan Bigg <radarlistener@gmail.com> wrote:> I had a crazy idea today based off a reader''s question[1]. > Why are rake db:migrate and rake db:test:prepare two different tasks? Why > can''t we have rake db:migrate migrate both the development and the test > database at the same time? So many noobs (I''ll include myself in that basket > too) get tripped up on this. How many times have you ran into it? > From what I can see, there is no reason at all why the development and test > databases should be different. What would you think about having these as > one task in Rails 3.0.1 or Rails 3.1, with obviously a deprecation warning > for rake db:test:prepare or something?Either that or dropping/loading the schema every time you require "test_helper" (or equivalent), but definitely +1> > [1] http://www.manning-sandbox.com/thread.jspa?threadID=39618&tstart=0 > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
One could take that idea a step further. Since many popular databases don''t support transactional DDL, it''s not hard to write a bad migration which fails and leaves the database stuck between migrations, requiring manual cleanup. If we did as you suggest, we could try to apply the migration first to the test database and only if it succeeded, try to apply it to the development database. If it failed, blowing away and recreating the test database would almost certainly be less painful than manually cleaning up development. - donald -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 21 September 2010 11:13, Donald Ball <donald.ball@gmail.com> wrote:> One could take that idea a step further. Since many popular databases > don''t support transactional DDL, it''s not hard to write a bad > migration which fails and leaves the database stuck between > migrations, requiring manual cleanup. If we did as you suggest, we > could try to apply the migration first to the test database and only > if it succeeded, try to apply it to the development database. If it > failed, blowing away and recreating the test database would almost > certainly be less painful than manually cleaning up development. >I love this idea of keeping the test database as a backup and rolling back to it. I can completely understand why development and test are two separate databases and this would solidify that even further. However, I can see a catch. If the test database is running then wouldn''t the data be wiped? Perhaps you would require this data for the development environment and if it''s gone, how are you going to get it back? Luckily there''s also a way around this. Any important development data should be easily recoverable by running rake db:seed, because you''ve got your important data in db/seeds.rb, right? Good to see there''s some support behind this :) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
This problem arises when you run the suite and there are pending migrations. So you are about to run tests, and the test tasks migrate... which environment? How do you know you are not in staging? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
This dual-migration should only happen if you''re in the development environment. If you''re in another environment such as staging it should only run it for the current environment. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
alternately, rather than change the behavior of the current rake tasks, it could be done by a separate task On 21-Sep-10, at 11:20 AM, Ryan Bigg wrote:> This dual-migration should only happen if you''re in the development > environment. If you''re in another environment such as staging it > should only run it for the current environment. > > -- > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails- > core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en > .-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Such as rake db:migrate:all? I like this idea too. On 21 September 2010 11:25, Mateo Murphy <mateo.murphy@gmail.com> wrote:> alternately, rather than change the behavior of the current rake tasks, it > could be done by a separate task > > > On 21-Sep-10, at 11:20 AM, Ryan Bigg wrote: > > This dual-migration should only happen if you''re in the development >> environment. If you''re in another environment such as staging it should only >> run it for the current environment. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 21 September 2010 16:26, Ryan Bigg <radarlistener@gmail.com> wrote:> Such as rake db:migrate:all? I like this idea too. > >IMHO rake db:migrate:local (simply means development and test) is a better name. rake db:migrate:all gives an impression that it will run migrations for all environments. andhapp> > On 21 September 2010 11:25, Mateo Murphy <mateo.murphy@gmail.com> wrote: > >> alternately, rather than change the behavior of the current rake tasks, it >> could be done by a separate task >> >> >> On 21-Sep-10, at 11:20 AM, Ryan Bigg wrote: >> >> This dual-migration should only happen if you''re in the development >>> environment. If you''re in another environment such as staging it should only >>> run it for the current environment. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Ruby on Rails: Core" group. >>> To post to this group, send email to rubyonrails-core@googlegroups.com. >>> To unsubscribe from this group, send email to >>> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/rubyonrails-core?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- Anuj DUTTA -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Sep 21, 2010 at 5:20 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> This dual-migration should only happen if you''re in the development > environment. If you''re in another environment such as staging it should only > run it for the current environment.But how can you tell from within the "test" environment? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
In that case then, rake db:migrate:all (or rake db:migrate:local) seems like a decent task name to run migrations on development+test only, no? On 21 September 2010 11:48, Xavier Noria <fxn@hashref.com> wrote:> On Tue, Sep 21, 2010 at 5:20 PM, Ryan Bigg <radarlistener@gmail.com> > wrote: > > > This dual-migration should only happen if you''re in the development > > environment. If you''re in another environment such as staging it should > only > > run it for the current environment. > > But how can you tell from within the "test" environment? > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
nothing intrigues me more than db:test:clone -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I personally have never used `rake db:test:prepare`. I generally use `rake db:migrate RAILS_ENV=test`. Something more concise is welcome. Allen Madsen http://www.allenmadsen.com On Tue, Sep 21, 2010 at 12:00 PM, radhames brito <rbritom@gmail.com> wrote:> > nothing intrigues me more than db:test:clone > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Not sure I follow. You do not need an extra task to run migrations in dev and test. Because the test database is loaded straight from db/schema.rb. The flow is: you run db:migrate in the environment you want, say "development". That dumps db/schema.rb as a side-effect, and the test tasks load that file. They do not use migrations. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Some test tools such as Cucumber (and I''m sure I''ve seen it in RSpec but I cannot reproduce it right now) do not run the migrations before they run the tests. I think Rails should automatically do it so that when you run the tests the database is already setup. Why run it every time when you should only run it once? This would speed up the execution of the tests. On 21 September 2010 12:04, Xavier Noria <fxn@hashref.com> wrote:> Not sure I follow. > > You do not need an extra task to run migrations in dev and test. > Because the test database is loaded straight from db/schema.rb. > > The flow is: you run db:migrate in the environment you want, say > "development". That dumps db/schema.rb as a side-effect, and the test > tasks load that file. They do not use migrations. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
If I understand you right, you''re saying `rake db:test:prepare` is synonymous with `rake db:schema:load RAILS_ENV=test` instead of migrate. Allen Madsen http://www.allenmadsen.com On Tue, Sep 21, 2010 at 12:04 PM, Xavier Noria <fxn@hashref.com> wrote:> Not sure I follow. > > You do not need an extra task to run migrations in dev and test. > Because the test database is loaded straight from db/schema.rb. > > The flow is: you run db:migrate in the environment you want, say > "development". That dumps db/schema.rb as a side-effect, and the test > tasks load that file. They do not use migrations. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Bingo. That''s all rake db:test:prepare does: loads the schema into the test database. Whereas rake db:test:clone clones the structure+data from the development database to the test database. On 21 September 2010 12:09, Allen Madsen <allen.c.madsen@gmail.com> wrote:> If I understand you right, you''re saying `rake db:test:prepare` > is synonymous with `rake db:schema:load RAILS_ENV=test` instead of migrate. > > Allen Madsen > http://www.allenmadsen.com > > > On Tue, Sep 21, 2010 at 12:04 PM, Xavier Noria <fxn@hashref.com> wrote: > >> Not sure I follow. >> >> You do not need an extra task to run migrations in dev and test. >> Because the test database is loaded straight from db/schema.rb. >> >> The flow is: you run db:migrate in the environment you want, say >> "development". That dumps db/schema.rb as a side-effect, and the test >> tasks load that file. They do not use migrations. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
When the test tasks warn that there are pending migrations they are not saying that you need to run migrations on the test schema. They are saying that db/schema.rb is outdated. And halt because normally that''s not good. Now, from within the "test" environment you do not have information to update db/schema.rb automatically. The task to fix that already exists, it is db:migrate. Perhaps a better error message? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
There may be valid reasons to not have your database on the most recent migration. It would be difficult for rails to know when it should go to the newest version and when it should stay at a particular one. Allen Madsen http://www.allenmadsen.com On Tue, Sep 21, 2010 at 12:06 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> Some test tools such as Cucumber (and I''m sure I''ve seen it in RSpec but I > cannot reproduce it right now) do not run the migrations before they run the > tests. I think Rails should automatically do it so that when you run the > tests the database is already setup. Why run it every time when you should > only run it once? This would speed up the execution of the tests. > > > On 21 September 2010 12:04, Xavier Noria <fxn@hashref.com> wrote: > >> Not sure I follow. >> >> You do not need an extra task to run migrations in dev and test. >> Because the test database is loaded straight from db/schema.rb. >> >> The flow is: you run db:migrate in the environment you want, say >> "development". That dumps db/schema.rb as a side-effect, and the test >> tasks load that file. They do not use migrations. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Sep 21, 2010 at 1:06 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> Some test tools such as Cucumber (and I''m sure I''ve seen it in RSpec but I > cannot reproduce it right now) do not run the migrations before they run the > tests. I think Rails should automatically do it so that when you run the > tests the database is already setup. Why run it every time when you should > only run it once? This would speed up the execution of the tests.What happens is that rails'', cucumber''s and rspec''s rake tasks run db:test:prepare before. But if you run a single test, like "ruby test/unit/model_test.rb", then the test database isn''t loaded. Maybe a simple solution for all this is providing a "rails/test/reset_database" that, when required, drops the database and requires Rails.root.join("db/schema"). That way we can include that in rails/test_help and everytime the file is loaded, whether from rake or an isolated test case being run, the database is up-to-date. Thoughts? -foca> On 21 September 2010 12:04, Xavier Noria <fxn@hashref.com> wrote: >> >> Not sure I follow. >> >> You do not need an extra task to run migrations in dev and test. >> Because the test database is loaded straight from db/schema.rb. >> >> The flow is: you run db:migrate in the environment you want, say >> "development". That dumps db/schema.rb as a side-effect, and the test >> tasks load that file. They do not use migrations. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, September 21, 2010 12:06, Ryan Bigg wrote:> Some test tools such as Cucumber (and I''m sure I''ve seen it in RSpec > but I cannot reproduce it right now) do not run the migrations > before theyIf you run rake cucumber then you get db:test:prepare as part of the cucumber task. If you run cucumber straight from the command line then you do not. I agree that db:migrate:whatever, when run in the development environment, should always produce db/schema.rb. It seems to me utterly pointless to have a test db that is not in sync with the current development db schema. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Rails sets up a test environment, you run tests via rake tasks for that reason.
The golden path is to run db:migrate if needed, eg after a pull got
new migrations, and then run the builtin testing tasks, or the ones
your 3rd party tool provides.
With TestUnit you run a single file this way:
rake test:units TEST=test/unit/user_test.rb
and one single test like this:
rake test:units TEST=test/unit/user_test.rb
TESTOPTS=''--name=test_sometest''
Other test frameworks should hook into the Rails tasks to offer a
similar workflow. You are not supposed to run files by hand.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Cucumber only provides a way to run individual tests through its "cucumber" executable. I don''t think it should be the responsibility of outside gems or even the built-in testing frameworks to run rake db:test:prepare before the tests themselves. The database should be taken care of when you run rake db:migrate for both the development AND test databases using the criteria I said earlier. On 21 September 2010 17:40, Xavier Noria <fxn@hashref.com> wrote:> Rails sets up a test environment, you run tests via rake tasks for that > reason. > > The golden path is to run db:migrate if needed, eg after a pull got > new migrations, and then run the builtin testing tasks, or the ones > your 3rd party tool provides. > > With TestUnit you run a single file this way: > > rake test:units TEST=test/unit/user_test.rb > > and one single test like this: > > rake test:units TEST=test/unit/user_test.rb > TESTOPTS=''--name=test_sometest'' > > Other test frameworks should hook into the Rails tasks to offer a > similar workflow. You are not supposed to run files by hand. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wednesday, September 22, 2010, Ryan Bigg <radarlistener@gmail.com> wrote:> Cucumber only provides a way to run individual tests through its "cucumber" executable. I don''t think it should be the responsibility of outside gems or even the built-in testing frameworks to run rake db:test:prepare before the tests themselves. > > The database should be taken care of when you run rake db:migrate for both the development AND test databases using the criteria I said earlier.Not saying that''s the job of an agnostic tool, in such case you would normally have a plugin that does whatever is needed to give you a normal workflow. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Sep 22, 2010 at 4:26 AM, James B. Byrne <byrnejb@harte-lyne.ca> wrote:> I agree that db:migrate:whatever, when run in the development > environment, should always produce db/schema.rb.It already does. The point is that unless you do a db:test:prepare, it''s not loaded into the test env yet. Whenever you run "rake" or "rake cucumber" or anything like that, db:test:prepare is then run; the debate here is whether it should be run at the time of migrate rather than test. I think a separate rake task that migrates and prepares test would be useful. Since I have one project still on mysql, I would be strongly opposed to having this done as a part of the normal db:migrate task, because it takes mysql about a minute to run the db:test:prepare with a moderate number of tables, and I don''t want to have to wait for that every time I migrate my development database. But db:migrate:whatever => [''db:migrate'', ''db:test:prepare''] would be useful. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wednesday, September 22, 2010, Will Bryant <will.bryant@gmail.com> wrote:> On Wed, Sep 22, 2010 at 4:26 AM, James B. Byrne <byrnejb@harte-lyne.ca> wrote: >> I agree that db:migrate:whatever, when run in the development >> environment, should always produce db/schema.rb. > > It already does. The point is that unless you do a db:test:prepare, > it''s not loaded into the test env yet. Whenever you run "rake" or > "rake cucumber" or anything like that, db:test:prepare is then run; > the debate here is whether it should be run at the time of migrate > rather than test. > > I think a separate rake task that migrates and prepares test would be > useful. Since I have one project still on mysql, I would be strongly > opposed to having this done as a part of the normal db:migrate task, > because it takes mysql about a minute to run the db:test:prepare with > a moderate number of tables, and I don''t want to have to wait for that > every time I migrate my development database. > > But db:migrate:whatever => [''db:migrate'', ''db:test:prepare''] would be useful.For me, personally, it is a smell that one needs to do that. The testing public contract uses tasks, a posterior such a compound task means that you''re not following the workflow. An integration plugin is missing, or whatever. You can of course implement that task yourself if you want to, eg if such plugin does not exist. On the other hand, I don''t like the idea of one environment touching another environment. Nor development, neither the rest. You have to think in the workflow for any given environment including custom ones, right? If I migrate the production database, that''s it, I don''t want that task to be messing with anything else. If Rails is setting up the test environement, that''s the logical moment to do any housekeeping. db/schema.rb is a bridge. Separation of concerns. I agree that you normally want your test database and whatever your environment is in sync. That''s why the task aborts if it is not. But I do think it is desirable that environments do not interfere with each other. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
The thing I "kinda" like about the current tasks is that they allow developers in legacy databases to override/extend them in such a way so they can support scripting the database. This is useful when you have things like stored procedures or DB specific data types. This process get''s even more complicated when the developer is on a platform that does not provide native binaries to do the job, for instance UNIX to a SQL Server database. This article [1] on our adapter''s wiki covers a process of extending rake so that you can do the equivalent of alias_method_chain for a rake task. The fact that there are discreet rake tasks that can be overridden or extended is a big asset to the edge cases others face, including myself at the day job. So my contribution to the conversation. If there is a core decision to consolidate things, just make sure you keep things far enough apart to accommodate those not living with a blessed db and work process. - Ken [1] http://wiki.github.com/rails-sqlserver/activerecord-sqlserver-adapter/rails-db-rake-tasks On Sep 21, 2010, at 6:08 PM, Ryan Bigg wrote:> Cucumber only provides a way to run individual tests through its "cucumber" executable. I don''t think it should be the responsibility of outside gems or even the built-in testing frameworks to run rake db:test:prepare before the tests themselves. > > The database should be taken care of when you run rake db:migrate for both the development AND test databases using the criteria I said earlier.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Sep 21, 2010 at 3:08 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> Cucumber only provides a way to run individual tests through its "cucumber" > executable.See http://wiki.github.com/aslakhellesoy/cucumber/using-rake require ''cucumber'' require ''cucumber/rake/task'' Cucumber::Rake::Task.new(:features) do |t| t.cucumber_opts = "--format pretty" end task :features => ''db:test:prepare''> I don''t think it should be the responsibility of outside gems or > even the built-in testing frameworks to run rake db:test:prepare before the > tests themselves.It''s the responsibility of anyone running tests -- whether test/unit, cucumber, autotest, textmate, etc -- to use the test harness.> The database should be taken care of when you run rake db:migrate for both > the development AND test databases using the criteria I said earlier.The test database is ephemeral. Imagine it is created just before the test run and destroyed just afterward. It is never migrated; it''s cloned on the fly *just for that test run.* Anything that expects greater responsibility or longevity from the test db raises red flags and design smells. jeremy -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, September 21, 2010 18:35, Will Bryant wrote:> On Wed, Sep 22, 2010 at 4:26 AM, James B. Byrne > <byrnejb@harte-lyne.ca> wrote: >> I agree that db:migrate:whatever, when run in the development >> environment, should always produce db/schema.rb. > > It already does. The point is that unless you do a db:test:prepare, > it''s not loaded into the test env yet. Whenever you run "rake" or > "rake cucumber" or anything like that, db:test:prepare is then run; > the debate here is whether it should be run at the time of migrate > rather than test.I see. I missed the distinction. My own workflow is that after any migration then I run rake cucumber, so I would not see this problem in the normal course of events. On the other hand I do recall being tripped up by this on at least one occasion. Some sort of automation of loading the test environment dbschema driven by db:migrate seems likely a worthwhile enhancement. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Sep 21, 2010 at 7:27 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote:> On Tue, Sep 21, 2010 at 3:08 PM, Ryan Bigg <radarlistener@gmail.com> wrote: > > The test database is ephemeral. Imagine it is created just before the > test run and destroyed just afterward. It is never migrated; it''s > cloned on the fly *just for that test run.* > > Anything that expects greater responsibility or longevity from the > test db raises red flags and design smells.This is a nice ideal. However I agree with others who say that when the schema gets large, recreating it can be slow. And slow tests are a nightmare. What if we could skip db:test:prepare if a NOPREP environment variable is given? Or had an extra set of tasks, say test:quick:unit etc, which skipped it? I''ve personally taken to doing the former in a large project. George -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Yea, I''ve done this too. Basically in my chained :clone_structure I copy the schema migrations to the test database and have the same task along with :dump noop unless the migrations are out of sync. This way I get to avoid a costly clone which takes almost 2 minutes for my legacy database. - Ken On Sep 24, 2010, at 12:45 AM, George wrote:> > This is a nice ideal. However I agree with others who say that when > the schema gets large, recreating it can be slow. And slow tests are a > nightmare. > > What if we could skip db:test:prepare if a NOPREP environment variable > is given? Or had an extra set of tasks, say test:quick:unit etc, which > skipped it? I''ve personally taken to doing the former in a large > project.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.