fixjour

Another fixture replacement. Gets you some methods (new_*, create_* and
valid_*_attributes) methods and some confidence.

View the RDoc (still underway, but has a bit of helpful stuff)

Recommend Me on the Working with Rails

Contribute

Fixjour has some developer dependencies. Install them as shown below,
and run rake to make sure the tests pass. Then dive in!

fixjour:$ gem build fixjour.gemspec
fixjour:$ sudo gem install --development fixjour
fixjour:$ rake
Do the tests pass?

The focus of this project is liberation through constraints.

It uses the bits of object mother systems that worked well for
me in the past, and actively discourages the bits that have caused
me pain.

The constraints:

One builder per model

If you try to define a builder more than once per model, you’ll
run into a Fixjour::RedundantBuilder error. One builder per
model decreases confusion.

No redundant object creation methods

If you try to define a method that’s already been defined by
a Fixjour builder, you’ll run into a Fixjour::RedundantBuilder
error. If you find the need to alter the behavior of a builder
for a particular set of tests, you should just wrap the creation
methods defined by Fixjour, preferably with a name that describes
how the new method is different from the Fixjour method.

Processing the overrides hash is bad

If you want to mess with the overrides hash that can be passed
into any of the creation methods, you must use the process
method (see below). To enforce this, the delete method is actually
private for the overrides hash.

What it gets you:

With this setup:

Fixjour do
  define_builder(Person) do |klass, overrides|
    klass.new(:name => 'Pat', :age => 22)
  end
end

include Fixjour

You get:

new_person(overrides={})

The new_person method basically just returns the result
of your builder block, which should always return an unsaved
instance of the model class. You can pass it overrides in a
hash like so: new_person(:name => nil).

create_person(overrides={})

The create_person method calls new_person, passing in any
overrides you pass it, calls save! on the result, and returns
the saved object.

valid_person_attributes(overrides={})

The valid_person_attributes returns a hash of valid person
attributes that are derived from the new_person method, and
ideal for things like testing controllers. It can also take
attribute override options like so: valid_person_attributes(:name => nil).

Usage:

You specify builder sets for your ActiveRecord models in a
Fixjour block using the define_builder helper, which can
be used in one of two ways:

Using a builder block

Pass define_builder a model class for which you want a new set
of creation methods, and a block which returns a new valid
model object. The block will be passed two arguments: a proxy
object for your class, and an overrides hash. If you call new
on the class proxy, it will return a new instance of the class,
with whatever attributes you specify as defaults. It will also
automatically merge any override options in all of the methods
generated by Fixjour.

Example:

define_builder(Person) do |klass, overrides|
  klass.new(:name => "Pat", :age => 22)
end

If you want to process an option in the overrides hash, you can use
the process method:

define_builder(Person) do |klass, overrides|
  overrides.process(:child) do |is_child|
    overrides[:age] = 14 if is_child
  end
  
  klass.new(:name => "Pat", :age => 22)
end

# the default
person = new_person
person.age # => 22

# using the override
person = new_person(:child => true)
person.age  # => 14

In the above example, the :child key will be deleted from the overrides
hash and made available as the is_child block argument where you can handle
things accordingly.

Note: The delete method is private on the overrides hash passed into the
builder block. This is meant to encourage you to only use the process method
instead. Why? First, because processing the overrides hash is a smell. Deal
with it. Second, using the process method provides some indication to readers
that you’re screwing with the overrides hash, and that’s a good thing.

attr_protected fields

If you have fields that cannot be mass-assigned, use the protected helper:

define_builder(Article) do |klass, overrides| klass.protected :author klass.new :title => “The title”, :body => “good”, :author => new_user end

If you use the protected helper to declare attr_protected fields, you can
then treat them the same as any other field in your test methods.

With Associations

To specify an associated object, you can call that object’s new_* method:

Fixjour do
  define_builder(Post) do |klass, overrides|
    klass.new(:name => 'a post', :body => 'texted')
  end
  
  define_builder(Comment) do |klass, overrides|
    klass.new(:body => 'Oh ok!', :post => new_post)
  end
end

include Fixjour

new_comment.post.name # => 'a post'

Note that it’s never a good idea to use a create_* method in a
build block.

Verifying your setups

Fixjour requires more work on your part, so it also includes a way
to verify that your creation methods are behaving the way they should.
Call Fixjour.verify! to ensure the following things:

1. Creation methods are returning valid objects by default.
2. new_* methods are returning new records.
3. new_* and create_* methods return instances of the correct class.

Recommended usage with RSpec and Cucumber

If you want to use Fixjour with RSpec and Cucumber you probably want to avoid adding the builder methods onto Object directly. To do this you should first create a file where your Fixjour builder definitions can live. Say for example you put it at spec/fixjour_builders.rb. To take advantage of these builders from RSpec use the following code in your spec_helper.rb:

require File.expand_path(File.dirname(__FILE__) + "/fixjour_builders.rb")

Spec::Runner.configure do |config|
  config.include(Fixjour) # This will add the builder methods to your ExampleGroups and not pollute Object
  ...
end

To use the same builders in Cucumber you simply need to include Fixjour into your World object from features/support/env.rb:

require File.expand_path(File.dirname(__FILE__) +'/../../spec/fixjour_builders.rb')
World { |world| world.extend(Fixjour) }

Be sure to do this after you define your World object. So, if you are using Rails you should include Fixjour after you require ‘cucumber/rails/world’.

In Cucumber version 0.2.3.2 and later you need to pass in a module to the World method to extend it:

require File.expand_path(File.dirname(__FILE__) +'/../../spec/fixjour_builders.rb')
World(Fixjour)

(See the Cucumber::StepMother#World RDoc or http://wiki.github.com/aslakhellesoy/cucumber/a-whole-new-world.)

Contributors

• Pat Maddox – Sparked the original idea and fixed my bugs
• Ben Mabey – Added docs and fixed my bugs
• Aaron Quint – Pointed out valid attrs problem and fixed my bugs

TODO

• There should be a Builder class.

Join the mailing list.

I’ve talked to smart people who like these instead:

• fixturereplacement
• factory girl

© Copyright 2008 Pat Nakajima, released under MIT License.