New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cucumber.rake should execute db:test:clone not test:prepare #278

Open
kramerdog opened this Issue Feb 26, 2014 · 7 comments

Comments

Projects
None yet
4 participants
@kramerdog

kramerdog commented Feb 26, 2014

As I just mentioned in $277 I did a
rails generate cucumber:install
on a new Rails 4 project today and couldnt work out why running rake cucumber didnt rebuild my test database

It took me ages to figure out but it seems that the Rails team have silently restructured the way that all of the Rake tasks work for cloning the structure of the development database to a freshly built test database.

From what I can tell the test:prepare task used to rebuild the test database. Now it appears from
...\lib\ruby\gems\2.0.0\gems\activerecord-4.0.3\lib\active_record\railties\databases.rake

that prepare is now only the task to 'Check for pending migrations and load the test schema'

I had to update all occurrences of test:prepare in cucumber.rake, such as in:

Cucumber::Rake::Task.new({:wip => 'test:prepare'}, 'Run features that are being worked on') do |t|
  t.binary = vendored_cucumber_bin
  t.fork = true # You may get faster startup if you set this to false
  t.profile = 'wip'
end

with db:test:clone to get rake cucumber to rebuild my test database prior to running mu cucumber features.

So shouldn't the cucumber.rake task generated now be using db:test:clone?

I should note that I am using

config.active_record.schema_format = :sql

in application.rb

and also had to add the line to application.rb:

ActiveRecord::Base.schema_format = config.active_record.schema_format

as a workaround as ActiveRecord::Base.schema_format was still being evaluated as :ruby in the clone task of databases.rake and is supposed to evaluate as :sql as a result of my config setting

ruby 2.0.0p353
rails 4.0.3
cucumber 1.3.10
cucumber-rails 1.4.0
OS Win64

@Kosmas

This comment has been minimized.

Show comment
Hide comment
@Kosmas

Kosmas Feb 26, 2014

Member

@kramerdog I believe it makes more sense to use the test:clone instead of test:prepare.
I am not sure if this causes any problems with earlier versions of rails.

Would you like to make a pull request with your changes and see if everything works?

Member

Kosmas commented Feb 26, 2014

@kramerdog I believe it makes more sense to use the test:clone instead of test:prepare.
I am not sure if this causes any problems with earlier versions of rails.

Would you like to make a pull request with your changes and see if everything works?

@kramerdog

This comment has been minimized.

Show comment
Hide comment
@kramerdog

kramerdog Feb 26, 2014

Again this should be dependent on the Rails version I guess as this only
seems to be the case for Rails 4.

I have fixed my immediate issue but wont be able to get to this for a while
I am afraid. May get to it eventually but just wanted to let you know of
the issue for now.

On Thu, Feb 27, 2014 at 2:22 AM, Kosmas Chatzimichalis <
notifications@github.com> wrote:

@kramerdog https://github.com/kramerdog I believe it makes more sense
to use the test:clone instead of test:prepare.
I am not sure if this causes any problems with earlier versions of rails.

Would you like to make a pull request with your changes and see if
everything works?

Reply to this email directly or view it on GitHubhttps://github.com//issues/278#issuecomment-36143774
.

kramerdog commented Feb 26, 2014

Again this should be dependent on the Rails version I guess as this only
seems to be the case for Rails 4.

I have fixed my immediate issue but wont be able to get to this for a while
I am afraid. May get to it eventually but just wanted to let you know of
the issue for now.

On Thu, Feb 27, 2014 at 2:22 AM, Kosmas Chatzimichalis <
notifications@github.com> wrote:

@kramerdog https://github.com/kramerdog I believe it makes more sense
to use the test:clone instead of test:prepare.
I am not sure if this causes any problems with earlier versions of rails.

Would you like to make a pull request with your changes and see if
everything works?

Reply to this email directly or view it on GitHubhttps://github.com//issues/278#issuecomment-36143774
.

@tooky

This comment has been minimized.

Show comment
Hide comment
@tooky

tooky Feb 27, 2014

Member

@kramerdog are you using rspec too? rspec-rails seems to be using test:prepare

test:prepare effectively calls test:load which checks the schema version and loads the DB as it should (see here) - then checks for pending migrations.

test:clone will dump a fresh schema/structure, and then load that into the test environment - it won't check for pending migrations.

@Kosmas it looks like rails are deprecating db:test:prepare and the other top level rake tasks, see here

Member

tooky commented Feb 27, 2014

@kramerdog are you using rspec too? rspec-rails seems to be using test:prepare

test:prepare effectively calls test:load which checks the schema version and loads the DB as it should (see here) - then checks for pending migrations.

test:clone will dump a fresh schema/structure, and then load that into the test environment - it won't check for pending migrations.

@Kosmas it looks like rails are deprecating db:test:prepare and the other top level rake tasks, see here

@kramerdog

This comment has been minimized.

Show comment
Hide comment
@kramerdog

kramerdog Feb 28, 2014

Hi Steve

Maybe I am just confused about things because I dont use migrations. And I
dont use rspec either I am afraid.

I use config.active_record.schema_format = :sql

When I start a test run I want a copy of my development database schema "as
is". When using "structure.sql" and not "schema.rb" it appears to me as
though in Rails 3 the test:prepare task dumped a new version of
structure.sql from development and then created test from that structure,
ignoring migrations. I may be wrong. But this worked as I wanted,
effectively cloning development to test.

Under Rails 4 the test:prepare task didnt appear to behave in this same way
which is why I changed it to test:clone. If this behaviour is not what
would be expected by anyone else then that is OK, I have just updated my
cucumber.rake to do what I want.

But it does seem to be the case that all the rake tasks have been changed
without it being apparent to me - cant see this being published anywhere?

On Fri, Feb 28, 2014 at 3:07 AM, Steve Tooke notifications@github.comwrote:

@kramerdog https://github.com/kramerdog are you using rspec too?
rspec-rails seems to be usinghttps://github.com/rspec/rspec-rails/blob/master/lib/rspec/rails/tasks/rspec.rake#L25
test:prepare

test:prepare effectively calls test:load which checks the schema version
and loads the DB as it should (see herehttps://github.com/rails/rails/blob/4-0-stable/activerecord/lib/active_record/railties/databases.rake#L313)

  • then checks for pending migrations.

test:clone will dump a fresh schema/structure, and then load that into
the test environment - it won't check for pending migrations.

@Kosmas https://github.com/Kosmas it looks like rails are deprecating
db:test:prepare and the other top level rake tasks, see herehttps://github.com/rails/rails/blob/4-1-stable/activerecord/lib/active_record/railties/databases.rake#L292

Reply to this email directly or view it on GitHubhttps://github.com//issues/278#issuecomment-36265051
.

kramerdog commented Feb 28, 2014

Hi Steve

Maybe I am just confused about things because I dont use migrations. And I
dont use rspec either I am afraid.

I use config.active_record.schema_format = :sql

When I start a test run I want a copy of my development database schema "as
is". When using "structure.sql" and not "schema.rb" it appears to me as
though in Rails 3 the test:prepare task dumped a new version of
structure.sql from development and then created test from that structure,
ignoring migrations. I may be wrong. But this worked as I wanted,
effectively cloning development to test.

Under Rails 4 the test:prepare task didnt appear to behave in this same way
which is why I changed it to test:clone. If this behaviour is not what
would be expected by anyone else then that is OK, I have just updated my
cucumber.rake to do what I want.

But it does seem to be the case that all the rake tasks have been changed
without it being apparent to me - cant see this being published anywhere?

On Fri, Feb 28, 2014 at 3:07 AM, Steve Tooke notifications@github.comwrote:

@kramerdog https://github.com/kramerdog are you using rspec too?
rspec-rails seems to be usinghttps://github.com/rspec/rspec-rails/blob/master/lib/rspec/rails/tasks/rspec.rake#L25
test:prepare

test:prepare effectively calls test:load which checks the schema version
and loads the DB as it should (see herehttps://github.com/rails/rails/blob/4-0-stable/activerecord/lib/active_record/railties/databases.rake#L313)

  • then checks for pending migrations.

test:clone will dump a fresh schema/structure, and then load that into
the test environment - it won't check for pending migrations.

@Kosmas https://github.com/Kosmas it looks like rails are deprecating
db:test:prepare and the other top level rake tasks, see herehttps://github.com/rails/rails/blob/4-1-stable/activerecord/lib/active_record/railties/databases.rake#L292

Reply to this email directly or view it on GitHubhttps://github.com//issues/278#issuecomment-36265051
.

@Kosmas

This comment has been minimized.

Show comment
Hide comment
@Kosmas

Kosmas Feb 28, 2014

Member

@tooky thanks!

I think it makes more sense like that.
You only need to make sure that you don't have any pending migrations, but from personal experience, that it should not be a problem.

I will have a look, but I believe that we should also change it and use the test:clone.

Member

Kosmas commented Feb 28, 2014

@tooky thanks!

I think it makes more sense like that.
You only need to make sure that you don't have any pending migrations, but from personal experience, that it should not be a problem.

I will have a look, but I believe that we should also change it and use the test:clone.

@tooky

This comment has been minimized.

Show comment
Hide comment
@tooky

tooky Feb 28, 2014

Member

@kramerdog looking at the tasks from rails 3.2 (here and here) you're right that it would dump the structure from development, then load that into test - but it would check for pending migrations.

I believe that checking for pending migrations before running the tests has bee the expected behaviour in a rails project as long as I've used it. If you have migrations that haven't been run on your database then how can you be sure that your tests (that hit the DB) are passing or failing correctly?

@Kosmas I think the best solution might be to add prepare task to cucumber - similar to rspec-rails which our tasks depend on - its then trivial for users to override that task with the behaviour they want. e.g. No / non-standard DB.

WDYT?

Member

tooky commented Feb 28, 2014

@kramerdog looking at the tasks from rails 3.2 (here and here) you're right that it would dump the structure from development, then load that into test - but it would check for pending migrations.

I believe that checking for pending migrations before running the tests has bee the expected behaviour in a rails project as long as I've used it. If you have migrations that haven't been run on your database then how can you be sure that your tests (that hit the DB) are passing or failing correctly?

@Kosmas I think the best solution might be to add prepare task to cucumber - similar to rspec-rails which our tasks depend on - its then trivial for users to override that task with the behaviour they want. e.g. No / non-standard DB.

WDYT?

@joallard

This comment has been minimized.

Show comment
Hide comment

joallard commented Dec 29, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment