Will Jessup is a founder and Managing Member of CitrusByte, a forward-thinking web application development business. Jessup talks about his company structure and how it attracts the best unique talent for his clients.

We will have the next Los Angeles Web Application Developers Meetup at AOL this month. We are only letting in 75 guests this time. RSVP asap to reserve your spot.

AOL is the sponsor of this months meetup on April 22nd at 8pm. We’ll get between 50-75 developers together and go over some quick presentations about new cool stuff , eat some pizza and chat. The presentation format is 5-10 minutes on something that web application developers should know, followed by 5 minutes Q&A. There are four open slots right now, so please send me your proposals for a presentation!

When?: Tuesday, Apr 22, 2008, 8:00 PM

Where?: AOL, 331 N Maple Dr, Beverly Hills, CA 90210

Join us at Los Angeles’s biggest meetup for web application developers. Find out what’s new in development for the web. Presenters will allow you to pick up a few tips and tricks and find out about new tools. After our presentations enjoy refreshments (and beer) and network with other local developers.

http://web.meetup.com/34/

The trouble w/ fixtures

I don’t use fixtures in my specs. At all. The fundamental issue with fixtures is that they setup a state for your database as a whole (or at least the tables you loaded). So when you use fixtures all your specs are running against essentially the same state. As you build your application and things get more complex your fixtures become more complex and your state grows and grows. The needs of your specs, however, should pretty much stay the same. So when you go back and track down an issue causing some spec to blow up you have to deal with that spec running in a state that’s way beyond it’s needs.

Brittle specs

For example, lets stay I’m writing a spec to ensure that book.authors.living does not return any deceased authors. The state that I need to spec this is very simple: 1 Book with 1 living Author and 1 dead Author. Then I just need to make sure that when I run book.authors.living I don’t get the dead Author back. It might look something like this:

describe Book do
  describe "with authors" do
    fixtures :books, :authors
 
    it "should only find living authors" do
      Book.find_by_title("Foo's Diary").authors.living.should == [Author.find_by_name('Jim')]
    end
  end
end

Assuming I know that Jim is alive this would be a good spec. The problem is as I write specs I’m going to add more and more authors and this spec will quickly blow up. It’s not blowing up because the .living method broke though, it’s just blowing up because it’s no longer running in the state it expected.

Kill your fixtures

Without fixtures I would do something like:

describe Book do
  describe "with authors" do
    before :each do
       @book = Book.create! :title => "Foo's Diary"
       @book.authors << (@jim = Author.new(:name => 'Jim', :dead => false))
       @book.authors << (@jeff = Author.new(:name => 'Jeff', :dead => true))
    end
 
    it "should only find living authors" do
      @book.reload.authors.living.should == [@jim]
    end
  end
end

Now my spec will always run in the state I gave it. So the things I setup for my other specs won’t come back and blow this spec up. Furthermore, the state isn’t buried in multiple fixture files. It’s defined plainly right above the spec(s) which use it.

Simplify your life even more

Once you ditch your fixtures you’ll find a new love for writing specs. There’s a couple handy tools to simplify your life further though:

Factories

Dan Manges blogged about using factories to simplify creation of classes and to provide defaults. Since then there’s been a few plugins developed for quick and easy factories. We’ve been using Scott Taylor’s Fixture Replacement.

add!

add is similar to the << method of has_many associations except it sacrifices chainability in order to return the concatenated object. add! goes a step further and throws an exception if the concatenation failed. This is useful in specs because the exception (probably due to a validation error) will occur in your state setup and you will see the error message in your output when you run your specs. So the reason your spec just blew up is displayed for you.

With Fixture Replacement and add! the example above would look something like:

describe Book do
  describe "with authors" do
    before :each do
       @book = create_book :title => "Foo's Diary"
       @jim = @book.authors.add! new_author(:name => 'Jim')
       @jeff = @book.authors.add! new_author(:name => 'Jeff', :dead => true)
    end
 
    it "should only find living authors" do
      @book.reload.authors.living.should == [@jim]
    end
  end
end

Here’s a little chunk of code I’ve been using recently. It gives you .add
and .add! methods on your has_many relationships that work similar to the << method. The difference is that .add sacrifices chain-ability in order to return the object being added to the collection.

Adding instead of concatenating

Using book.authors << Author.new(:name => ‘Geoff’) returns true or false forcing you to do something like book.authors << (geoff = Author.new(:name => ‘Geoff’)) to maintain a reference to the new object. Using .add you can do geoff = book.authors.add Author.new(:name => 'Geoff')

No really…add!ing

Perhaps even more helpful (especially in specs) is the add! method. add! acts just like add except it raises a RecordInvalid exception on failure. So you can do geoff = book.authors.add! Author.new(:name => 'Geoff') and have your execution (or your transaction) halt if Geoff messed up and wasn’t valid.

Blowing up your specs

This comes in handy a lot in your specs as exceptions will be displayed as the reason for failure. So if you were to add a validation to your Author class that caused all the Author’s you were adding to Book’s all over your specs to be invalid, you would see it (along with your validation’s helpful error message) when you ran your specs.

The goods

Just drop this in a file in your /lib folder and require it in an initializer.

module ActiveRecord
  module Associations
    class AssociationCollection < AssociationProxy #:nodoc:
      # works just like << except returns the added records instead of self, so
      # it's not chainable but allows you to do something like:
      #   @jim = Book.authors.add Author.new(:name => 'jim')
      # (often saving a whole line of code!)
      def add(*records)
        self.<<(*records)
        unarray_if_lonely(records)
      end
 
      # works just like add except raises an exception on error
      def add!(*records)
        raise RecordInvalid.new(*records) unless self.<<(*records)
        unarray_if_lonely(records)
      end
 
      # if the given object is an array of size 1 then it returns the only
      # element itself (w/ no array), otherwise it just gives back object
      def unarray_if_lonely(object)
        (object.is_a?(Array) && object.length == 1) ? object.first : object
      end
    end
  end
end