Test Rake Tasks Like a BOSS

Testing Rake tasks is one of the most painful things I do as a Ruby developer. Even after extracting all the code out into a separate class (which helps a lot), I still want to make sure I test that the right classes got called correctly with the right arguments.

I wanted the subject to be the task, where I could call invoke, check its prerequisites, etc.

describe "cron:hourly" do
  its(:prerequisites) { should include("reports:users") }
end

describe "reports:users" do
  before { ReportGenerator.stubs(:generate) }

  its(:prerequisites) { should include("environment") }

  it "generates the report" do
    subject.invoke
    ReportGenerator.should have_received(:generate).with()
  end
end

RSpec has shared contexts, so I set off to find an easy, straightforward way to test Rake tasks.

# spec/support/shared_contexts/rake.rb
require "rake"

shared_context "rake" do
  let(:rake)      { Rake::Application.new }
  let(:task_name) { self.class.top_level_description }
  let(:task_path) { "lib/tasks/#{task_name.split(":").first}" }
  subject         { rake[task_name] }

  def loaded_files_excluding_current_rake_file
    $".reject {|file| file == Rails.root.join("#{task_path}.rake").to_s }
  end

  before do
    Rake.application = rake
    Rake.application.rake_require(task_path, [Rails.root.to_s], loaded_files_excluding_current_rake_file)

    Rake::Task.define_task(:environment)
  end
end

This shared context is doing a lot, so I’ll walk through some of the odd areas and explain what’s happening.

The second let (task_name) is grabbing the top level description. That means it’ll use the text we pass to describe to calculate the task we’re going to run.

describe("reports:user") { } # subject is Rake::Task["reports:user"]

task_path is the path to the file itself, relative to Rails.root. We can infer path based off of the description, so for the describe above, it’ll assume the rake task is in lib/tasks/reports.rake.

Thirdly, loaded_files_excluding_current_rake_file - this requires a bit of explanation, even with that really descriptive method name. Rake is kind of a pain in certain cases; The rake_require method takes three arguments: the path to the task, an array of directories to look for that path, and a list of all the files previously loaded. rake_require takes loaded paths into account, so we exclude the path to the task we’re testing so we have the task available. This only matters when you’re running more than one test on a rake task, but there’s no harm in doing this every time we test so that there aren’t odd edge cases out there.

Finally, I define the :environment task (which most tasks defined in a Rails app will have as a prerequisite, since it’ll load the Rails stack for accessing models and code within lib without any additional work.

That’s the shared context in a nutshell; here’s what it allows us to do.

The tasks:

# lib/tasks/reports.rake
namespace :reports do
  desc "Generate users report"
  task :users => :environment do
    data = User.all
    ReportGenerator.generate("users", UsersReport.new(data).to_csv)
  end

  desc "Generate purchases report"
  task :purchases => :environment do
    data = Purchase.valid
    ReportGenerator.generate("purchases", PurchasesReport.new(data).to_csv)
  end

  desc "Generate all reports"
  task :all => [:users, :purchases]
end

And the tests:

# spec/lib/tasks/reports_rake_spec.rb
describe "reports:users" do
  include_context "rake"

  let(:csv)          { stub("csv data") }
  let(:report)       { stub("generated report", :to_csv => csv) }
  let(:user_records) { stub("user records for report") }

  before do
    ReportGenerator.stubs(:generate)
    UsersReport.stubs(:new => report)
    User.stubs(:all => user_records)
  end

  its(:prerequisites) { should include("environment") }

  it "generates a registrations report" do
    subject.invoke
    ReportGenerator.should have_received(:generate).with("users", csv)
  end

  it "creates the users report with the correct data" do
    subject.invoke
    UsersReport.should have_received(:new).with(user_records)
  end
end

describe "reports:purchases" do
  include_context "rake"

  let(:csv)              { stub("csv data") }
  let(:report)           { stub("generated report", :to_csv => csv) }
  let(:purchase_records) { stub("purchase records for report") }

  before do
    ReportGenerator.stubs(:generate)
    PurchasesReport.stubs(:new => report)
    Purchase.stubs(:valid => purchase_records)
  end

  its(:prerequisites) { should include("environment") }

  it "generates an purchases report" do
    subject.invoke
    ReportGenerator.should have_received(:generate).with("purchases", csv)
  end

  it "creates the purchase report with the correct data" do
    subject.invoke
    PurchasesReport.should have_received(:new).with(purchase_records)
  end
end

describe "reports:all" do
  include_context "rake"

  its(:prerequisites) { should include("users") }
  its(:prerequisites) { should include("purchases") }
end

Some people may say, “This is overkill! I tested the classes in other areas!” To me, that’s just like saying, “I’ve written unit and functional tests so I don’t need to write integration tests.” If you have a rake task that needs to be run (cron on Heroku, for example), would you leave that code untested? I wouldn’t.

Have you extracted out a pattern for testing Rake tasks? I’d love to hear about it; maybe a patch to RSpec is in order!

Sign up to receive a weekly recap from thoughtbot