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

[kramerdog]

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]

@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]

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]

@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]

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]

@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]

@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]

Probably relevant: rails/rails#13528 and ActiveRecord::Migration.maintain_test_schema!

[luke-hill]

Apologies for dredging up a seriously old topic. But figured given we will drop rails 4 support soon for cucumber-rails (We only support 4.2 at the moment as a minimum), I was wondering if this is still an issue.

I had a brief look into the things linked here, and from what tooky said about adding an additional task to the default is definitely not a problem. Is this something you would want?

cc/ @kramerdog @joallard

[joallard]

Yeah, it's been too long, I don't think this is relevant to me anymore.

[luke-hill]

I'll keep monitoring this for a while then close if appropriate.