Presenter Test

gistfile1.rb

require 'date'
require 'awesome_print'
require File.expand_path(__FILE__ + "/../../../app/presenters/job_presenter")

class Job
  attr_accessor :due_by
  def initialize(due_by)
    @due_by = due_by
  end
end

describe JobPresenter do
  it "returns all past due jobs" do
    jobs = [Job.new(:due_by => Date.today), 
            Job.new(:due_by => Date.today), 
            Job.new(:due_by => Date.today - 1)]
    presenter = JobPresenter.new(jobs)
    presenter.should be_something # assert some condition
  end
end

Yay Ruby!!

Curious about the opinions of those more experienced with MVP and isolated testing in Rails than I am. Starting to experiment and I am not sure if I like creating a mock class to give me what I care about from my AR class. In this case, I only care about due_by. Or, if there is a better style that I am not aware of.

My first inclination would be to set up a Fabricator or Factory Girl builder for making actual instances of your AR class. It's easy to set up a few base flavors of your class, then modify them to suit your specific tests if you need to. I imagine that as your app gets more sophisticated your presenter is going to look for things beyond just a due date, in which case your tests will break even though your code might still work.

The only other "better" option I can think of would be to use a mocking / stubbing library to define a fake Job and the methods it should respond to. It's a touch more flexible than actually building out a class in your test file, and reads a little easier in the test environment to begin with. That having been said, I'm still very much in favor of the Fabricator style of testing here.

FactoryGirl is a good idea and I use it often. If testing in isolation, does it make sense to limit dependencies? I wonder if I could just edit the class as I go to include the things that I care about without adding a fabricator dependency, I am under the impression that this helps keep the code modular and simple.

For example, if I added a test for a unique job number, I could simply add job_number to the attr_accessor and initializer, build jobs the same way, and test the logic and output.