Rake features does not seem to run rake db:test:prepare


#1

This may be misunderstanding on my part but I thought that running rake
features would automatically run rake db:test:prepare. However, this
does not seem to be the case. Am I mistaken or is this a bug?

The rake task I am using is this:

#in ./lib/tasks/cucumber.rake
desc “Exercise cucumber features”
task :features => ‘db:test:prepare’
task :features => “features:all”
#task :features => ‘db:test:prepare’
require ‘cucumber/rake/task’ #I have to add this -mischa

namespace :features do
Cucumber::Rake::Task.new(:all) do |t|
t.cucumber_opts = “–format pretty”
end

Cucumber::Rake::Task.new(:cruise) do |t|
t.cucumber_opts = “–format pretty
–out=#{ENV[‘CC_BUILD_ARTIFACTS’]}/features.txt --format html
–out=#{ENV[‘CC_BUILD_ARTIFACTS’]}/features.html”
t.rcov = true
t.rcov_opts = %w{–rails --exclude osx/objc,gems/,spec/}
t.rcov_opts << %[-o
“#{ENV[‘CC_BUILD_ARTIFACTS’]}/code_coverage/features”]
end

Cucumber::Rake::Task.new(:rcov) do |t|
t.rcov = true
t.rcov_opts = %w{–rails --exclude osx/objc,gems/,spec/}
t.rcov_opts << %[-o “code_coverage/features”]
end
end

I moved the task :features => ‘db:test:prepare’ statement from after
task :features => “features:all” to before it, but this does not
influence the observed behaviour.

This issue came to my attention when I discovered that changes to the
migrations were not showing up in the test database unless I manually
did rake db:test:prepare.


#2

James B. wrote:

I moved the task :features => ‘db:test:prepare’ statement from after
task :features => “features:all” to before it, but this does not
influence the observed behaviour.

I lied. Evidently moving the the db:test:prepare statement did resolve
the problem after all.


#3

On Tue, Jan 27, 2009 at 9:13 AM, James B. removed_email_address@domain.invalid
wrote:

When in doubt, run rake with --trace, and you’ll see 1) which tasks are
considered as prequisites, and 2) which of these are actually run.

For example, I tend to do ‘rake db:migrate:redo’ when I’m writing a
migration, in order to make sure the migration is downable as well as
upable. However, I found that it was leaving schema.rb in the ‘down’
state.
Running rake with --trace showed me that the task of writing schema.rb
was a
prerequisite for both the down and the up - but the dependency had been
satisifed by the first invovation, hence it didn’t write schema.rb again
after the up.

///ark