Why are my Cucumber Rake Tasks executing even though I did not ask them to?

I'm struggling with understanding how Rake processes Cucumber tasks. I'm probably doing this wrong, but can't see what the "right" way is.

I've got the following tasks:

namespace :features do

  Cucumber::Rake::Task.new(:browser, 'Run Cucumber Features using a Browser') do |t|
    t.profile = ENV['HUDSON'] ? 'browser_hudson' : 'browser' 
    setup_environment
    check_profile(t.profile)
  end

  Cucumber::Rake::Task.new(:headless, 'Run Cucumber Features using a Headless Browser') do |t|
    t.profile = ENV['HUDSON'] ? 'hudson' : 'default' 
    setup_environment
    check_profile(t.profile)
  end
end

This seems straight forward to me.

The problem is when I run any of the cucumber tasks, I'm seeing both tasks execute. So if I do:

rake features:browser

or

rake features:headless

I see setup_environment and check_profile run twice, and then the actual task getting invoked. I end up seeing something like this:开发者_StackOverflow

setup_environment called
check_profile called, running in browser
setup_environment called
check_profile called, running headless
** Invoke features:browser (first_time)
** Execute features:browser

And of course, it's now running headless.

I'm guessing I shouldn't be doing any "work" inside the task definition for a Cucumber task. Is there an alternative I should be looking into to accomplish this problem?

---

I resolved this issue by doing the following:

task :browser => ['features:setupenv', 'features:isbrowser', 'features:browser'] do
end

task :headless => ['features:setupenv', 'features:headless'] do
end

The two new features tasks are:

task :setupenv do
  setup_environment
end

task :isbrowser do
  ENV['BROWSER'] ||= 'true'
end

This works, but still doesn't answer the question why Cucumber tasks operate differently from standard Rake tasks. I guess it's a bad assumption on my part that Cucumber rake tasks extended a standard Rake task, when what's really happening is a Rake Task is being constructed dynamically. In order for that to happen, the code needs to execute, rather than act as a pointer to that code for execution later (which is what I assumed would happen)