Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Tools
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker
Joe Moore

DRY, Targeted, and Reusable Testing of ActiveRecord Extensions

Joe Moore
Wednesday, March 18, 2009

At Pivotal, we are passionate about test driven development, keeping things DRY, and writing readable and understandable code. Satisfying all of these desires can be challenging, especially when writing test code. In particular, ActiveRecord extensions present several challenges: which models using an extension should we test? How do we both test our extension in isolation while also testing all model’s usage of that extension? Is it even worth it?

The answer is yes, it is worth it, and it’s also fairly easy, readable, understandable, and DRY. I will present both a common problem and a solution, using a cumulation of technologies and techniques from multiple Pivotal projects, in particular using acts_as_fu to create laser-targeted, isolated, and disposable ActiveRecord models for testing extensions and RSpec shared behaviors to minimize the amount of duplicated test code.

Often we find common patterns in ActiveRecord models and we wish to share that functionality by mixing in a module of shared code, or even mixing that module in to ActiveRecord::Base itself. How should we go about testing these ActiveRecord extensions? Not only do we want to test the extension, but also test that models using that extension are doing so properly. We’ve blogged about dynamically creating ActiveRecords to test extensions in the past, but Pivot Pat Nakajima’s acts_as_fu plugin is a far better tool for this.

The Setup

Let’s say we have three models: Pivotal, Lab, and Pivot. Both a Pivot and a Lab belongs_to Pivotal, have a name, nickname, some common validation, etc:

# app/models/pivotal.rb
class Pivotal < ActiveRecord::Base
end

# app/models/lab.rb
class Lab < ActiveRecord::Base
  RANDOM_NICKNAMES = ["New Hotness", "LOL-Cat Factory", "Tweet Machine"]
  belongs_to :pivotal
  validates_presence_of :name

  def nickname
    "#{self.name}, 'The #{RANDOM_NICKNAMES[rand(RANDOM_NICKNAMES.length)]}'"
  end
end

# app/models/pivot.rb
class Pivot < ActiveRecord::Base
  RANDOM_NICKNAMES = ["New Hotness", "LOL-Cat Factory", "Tweet Machine"]
  belongs_to :pivotal
  validates_presence_of :name

  def nickname
    "#{self.name}, 'The #{RANDOM_NICKNAMES[rand(RANDOM_NICKNAMES.length)]}'"
  end
end

The specs for Lab and Pivot might look like the following:

# spec/models/lab_spec.rb
describe Lab do
  before(:each) do
    @lab = Lab.new
  end

  it "should require name" do
    @lab.should have(1).errors_on(:name)
    @lab.name = 'Stealth Startups'
    @lab.should have(0).errors_on(:name)
  end

  it "should generate a random nickname" do
    @lab.name = 'Stealth Starup'
    @lab.nickname.should_not be_blank
    @lab.nickname.should include(@lab.name + ", 'The ")
  end

  it "should belong to Pivotal" do
    @lab.should respond_to(:pivotal)
    @lab.should respond_to(:pivotal=)
    @lab.should respond_to(:pivotal_id)
    @lab.should respond_to(:pivotal_id=)
  end
end

# spec/models/pivot_spec.rb
describe Pivot do
  before do
    @pivot = Pivot.new
  end

  it "should require name" do
    @pivot.should have(1).errors_on(:name)
    @pivot.name = 'Joe Moore'
    @pivot.should have(0).errors_on(:name)
  end

  it "should generate a random nickname" do
    @pivot.name = 'Joe Moore'
    @pivot.nickname.should_not be_blank
    @pivot.nickname.should include(@pivot.name + ", 'The ")
  end

  it "should belong to Pivotal" do
    @pivot.should respond_to(:pivotal)
    @pivot.should respond_to(:pivotal=)
    @pivot.should respond_to(:pivotal_id)
    @lab.should respond_to(:pivotal_id)
  end
end

DRYing Up the Models

Yuck, look at all that duplication! Let’s start eliminating it by pulling the common model code into an ActiveRecord extension named belongs_to_pivotal:

# lib/belongs_to_pivotal.rb
module BelongsToPivotal
  RANDOM_NICKNAMES = ["New Hotness", "LOL-Cat Factory", "Tweet Machine"]
  module ClassMethods
    def belongs_to_pivotal
      belongs_to :pivotal
      validates_presence_of :name

      instance_eval do
        include BelongsToPivotalInstanceMethods
      end
    end
  end

  module BelongsToPivotalInstanceMethods
    def nickname
      "#{self.name}, 'The #{BelongsToPivotal::RANDOM_NICKNAMES[rand(BelongsToPivotal::RANDOM_NICKNAMES.length)]}'"
    end
  end

  def self.included(base)
    base.extend(ClassMethods)
  end
end

Now our Models look like this:

# app/models/lab.rb
class Lab < ActiveRecord::Base
  belongs_to_pivotal
end

# app/models/pivot.rb
class Pivot < ActiveRecord::Base
  belongs_to_pivotal
end

You’ll need to add “ActiveRecord::Base.send :include, BelongsToPivotal” to config/initializers/new_rails_defaults.rb or some other initializer.

Testing the Extension with acts_as_fu

The models are looking better, but what about the specs? In the “old days” I would create a spec named belongs_to_pivotal_spec.rb and use one of the two Models in that spec. But, when you do that, you get all the the “baggage” from that Model, such as any other methods, associations, inherited methods and properties, etc. Let’s use acts_as_fu to write a spec that tests BelongsToPivotal in isolation.

# spec/lib/belongs_to_pivotal_spec.rb
describe BelongsToPivotal do
  before(:all) do
    # Using acts_as_fu to create a model specifically for our extension
    build_model :belongs_to_pivotal_models do
      # we will need these columns in the database
      string :name
      integer :pivotal_id

      # Call our extension here
      belongs_to_pivotal
    end
  end

  before(:each) do
    @pivotal_model = BelongsToPivotalModel.new
  end

  # Look, it's all of the model specs!
  it "should require name" do
    @pivotal_model.should have(1).errors_on(:name)
    @pivotal_model.name = 'Pivotal Model'
    @pivotal_model.should have(0).errors_on(:name)
  end

  it "should generate a random nickname" do
    @pivotal_model.name = 'Pivotal Model'
    @pivotal_model.nickname.should_not be_blank
    @pivotal_model.nickname.should include(@pivotal_model.name + ", 'The ")
  end

  it "should belong to Pivotal" do
    @pivotal_model.should respond_to(:pivotal)
    @pivotal_model.should respond_to(:pivotal=)
    @pivotal_model.should respond_to(:pivotal_id)
    @pivotal_model.should respond_to(:pivotal_id=)
  end
end

Now that our ActiveRecord extension is well tested, how do we make sure that our two models are actually using it? One technique is to check that each model responds to the specific methods added by our extension:

#spec/models/lab_spec.rb
describe Lab do
  ...
  it "should belong_to_pivotal" do
    @lab.should respond_to(:pivotal)
    @lab.should respond_to(:pivotal=)
    @lab.should respond_to(:pivotal_id)
    @lab.should respond_to(:pivotal_id=)
    @lab.should respond_to(:name)
    @lab.should respond_to(:name=)
    @lab.should respond_to(:nickname)
  end
  ...

This does not feel very satisfying. We are duplicating some of the tests from belongs_to_pivotal_spec.rb and not verifying that we are getting the validations. A crazy coincidence could result in these methods all being defined without actually using our extension.

Another technique, though some would call it a hack, is to provide a hook within the extension itself so we can check for it later:

# lib/belongs_to_pivotal.rb
module BelongsToPivotal
  ...
  module ClassMethods
    ...
    # We can check this to see if a model uses this extension
    def belongs_to_pivotal?
      self.included_modules.include?(BelongsToPivotalInstanceMethods)
    end
  end
  ...
end

Let’s update belongs_to_pivotal_spec.rb to test this method:

# spec/lib/belongs_to_pivotal_spec.rb
describe BelongsToPivotal do
  before(:all) do
    # Using acts_as_fu to create a model specifically for our extension
    build_model :belongs_to_pivotal_models do
      ...
    end

    # Create a model that does not use our extension
    build_model :never_belongs_to_pivotal_models do
      # do nothing
    end
  end
  ...
  it "should know if it belongs_to_pivotal" do
    BelongsToPivotalModel.belongs_to_pivotal?.should be_true
    NeverBelongsToPivotalModel.belongs_to_pivotal?.should be_false
  end
end

#spec/models/lab_spec.rb
describe Lab do
  it "should belong_to_pivotal" do
    Lab.belongs_to_pivotal?.should be_true
  end
end

#spec/models/pivot_spec.rb
describe Pivot do
  it "should belong to Pivotal" do
    Pivot.belongs_to_pivotal?.should be_true
  end
end

Using RSpec Shared Behaviors

How much further can we go? Notice that our two Model specs are 5 whole lines long! Unacceptable! All kidding aside, we can DRY this up just a bit more by using RSpec’s shared behaviors.

In spec/spec_helper.rb

# spec/spec_helper.rb
describe 'it belongs to pivotal', :shared => true do
  it "should belongs_to_pivotal" do
    described_class.belongs_to_pivotal?.should be_true
  end
end

Now we can use this shared behavior in our specs:

#spec/models/lab_spec.rb
describe Lab do
  it_should_behave_like "it belongs to pivotal"
end

#spec/models/pivot_spec.rb
describe Pivot do
  it_should_behave_like "it belongs to pivotal"
end

I hope that these techniques are helpful. Feel free to post your own!

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Pivotal Labs

Best Buy Remix @ SXSW

Pivotal Labs
Saturday, March 14, 2009

I’m here as part of the Best Buy Remix crew, hanging out in Mashery’s Circus Mashimus all weekend. Come by, have a beer, and check out Remix and other interesting API stuff if you’re at SXSW.

We’re in a room near the front of the convention center, not far from the Pepsi booth.

-Steve

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Pivotal Labs

New York Standup 03/12/2009

Pivotal Labs
Friday, March 13, 2009

Interesting

  • Ben noted, you can give your Ruby command-line tools some (RDoc::)usage
  • Rails Boost, where one may “generate a … bootstrapped Rails app”, now includes fixjour as an option to the generator
  • Joe and Ryan recently created a Pivotal fork of Pat‘s acts_as_fu to get it to play nicely with your application and its database connections
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Pivotal Labs

New York Standup 03/11/2009

Pivotal Labs
Wednesday, March 11, 2009

Help Wanted

  • We’re interested in running some sort of javascript validation and syntax checking suite on one of our projects. JSLint looks reasonable for the framework and can be run from the command line with Rhino.

    If you have experience with or thoughts about the idea, please share.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Pivotal Labs

New York Standup, Overdue from the Week of 03/02/2009

Pivotal Labs
Wednesday, March 11, 2009

Interesting Things

  • An EngineYard-hosted project had an issue with monit attempting to restart
    mongrel too often. It turned out that the mongrel processes were not
    dropping pid files soon enough. The EngineYard-suggested fix:

    • Upgrade mongrel to 1.1.5.1 (patched to drop the pid file faster)
    • Upgrade to monit 5.0 beta 6
    • Update to the latest ey-monit-scripts
  • FiveRuns dash is a cool, customizable metrics
    service. Pat created a plug-in
    for sending continuous integration stats there: dash-ci.
  • Using Cucumber to test Capistrano deployment:

    cap --dry-run will run Capistrano without completing the actual task
    (e.g., deployment). Cucumber can then be used to write some nice,
    story-like deployment expectations that search the Capistrano output to
    document your project’s deployment process and ensure the documentation
    remains valid. Something like:

    Feature: Deployment
      In order to deploy the application
      As an administrator
      I should run Capistrano commands
    
    
      Scenario: Deploying
        Given I am working from the RAILS_ROOT directory
          And the parent directory is a Git repository
        When  I run a deployment task
        Then  'scm_user' for the deployment should be derived from the Git config for the remote origin
    
    
      Scenario: Deploying to demo
        Given I am working from the RAILS_ROOT directory
        When  I run 'cap demo deploy'
        Then  the deploy should succeed
          And the deployed code matches the latest 'web/stable' tag
          And the deployed code should be marked with a new 'web/demo' tag
    

    More on this to come.

  • Using Selenium to ensure unique IDs in your DOM:

    # ----------------------------------------------------------------------
    # The examples below illustrate the technique with the Prototype and
    # jQuery libraries, respectively.  Both use Pat Nakajima's selenium
    # helper for executing javascript in the tested browser window.
    #
    # For more on that helper, see:
    # http://pivotallabs.com/users/patn/blog/articles/717-run-javascript-in-selenium-tests-easily-
    # ----------------------------------------------------------------------
    
    
    # ----------------------------------------------------------------------
    # with prototype
    # note the exception catching... prototype chokes on invalid IDs
    # e.g., "invalid_id[][]"
    # ----------------------------------------------------------------------
    def assert_unique_ids
      audit_json = run_javascript <<-JS
        audit_ids = function() {
          var results = {};
          $A($$('*[id]')).each(function(element) {
            if(element.id.replace(' ', '').length > 0) {
              try {
                if($$('#' + element.id ).length > 1) {
                  if( ! results.duplicates) {
                    results.duplicates = {};
                  }
                  var count = results.duplicates[element.id] || 0;
                  count ++;
                  results.duplicates[element.id] = count;
                }
              }
              catch(err) {
                // uncomment to capture invalid IDs
                // var invalid = results.invalid || [];
                // invalid.push(element.id);
                // results.invalid = invalid;
              }
            }
          });
          return ($H(results).toJSON());
        }
        audit_ids();
      JS
      assert_equal({}, JSON.parse(audit_json)), 'Expected no duplicate IDs')
    end
    
    
    # ----------------------------------------------------------------------
    # with jQuery
    # additionally depends on the jquery-json plugin:
    # http://code.google.com/p/jquery-json/
    # ----------------------------------------------------------------------
    def assert_unique_ids
      audit_json = run_javascript <<-JS
        audit_ids = function() {
          var results = {};
          $('*[id]').each(function() {
            if(this.id.replace(' ', '').length > 0) {
              if($('*[id=' + this.id + ']').length > 1) {
                if( ! results.duplicates) {
                  results.duplicates = {};
                }
                var count = results.duplicates[this.id] || 0;
                count ++;
                results.duplicates[this.id] = count;
              }
            }
          });
          return $.toJSON(results);
        }
        audit_ids();
      JS
      assert_equal({}, JSON.parse(audit_json)), 'Expected no duplicate IDs')
    end
    

Help Wanted

  • One project recently moved from Rimu to EngineYard, only to find their Mongrel processes double in memory consumption. Any thoughts on why?
  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Joseph Palermo

Standup 03/06/2009

Joseph Palermo
Saturday, March 7, 2009

Interesting Things

  • If you’re using ack in project for textmate, be sure to edit your .ackrc file to include any non-standard file types you’re using.

  • A project had a dramatic speed up in their test suite by mocking out ActionMailer in tests. Something to consider if your tests cause a lot of email side effects.

  • field_named wasn’t working for us when using Webrat to drive Selenium. Our fork with the simple fix can be found here.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Dan Podsedly

Public projects in Pivotal Tracker

Dan Podsedly
Saturday, March 7, 2009

If you use Pivotal Tracker for open source projects, and would like to increase visibility into what your team is working on, you can now do so by making your Tracker project public.

As a project owner, you can enable public access for your project on the Project Settings page, by selecting the Public Access checkbox. The public URL to the project is to the right of the checkbox, in the format http://www.pivotaltracker.com/projects/xxx, where xxx is the id of the project. You can also append a dash to that URL, with a more descriptive name of your project, for example http://www.pivotaltracker.com/projects/xxx-My-Cool-Project.

Anyone you give the project URL to will be able view stories in your project, without having to sign in to Tracker. They’ll also be able request project membership by clicking the “Join This Project” button.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Joseph Palermo

Standup 03/05/2009

Joseph Palermo
Friday, March 6, 2009

Interesting Things

  • Giving your fake acts_as_fu model the same name as an actual model you have can lead to very obscure test failures. For those not in the know, acts_as_fu gives you the ability to test your model extensions directly by creating a fake model in your tests and mixing your extensions into it.

  • A few people have been using Paperclip to manage their attachments and have found it easier to integrate than Attachment_fu.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Joseph Palermo

Standup 03/04/2009

Joseph Palermo
Wednesday, March 4, 2009

Interesting Things

Integer("008") != "008".to_i
  • The to_i method is what you want, unless you want exceptions or octal numbers.

  • Somebody needed help constructing a named_scope where they could reference the count of an associated has_many association. There was some grumbling about using :joins and :group (and if you do this, be sure not to call count on the scope itself without also doing a :select => 'DISTINCT primary_key'). The winning solution was to just put a counter_cache on the association and use the denormalized column instead.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter
Joseph Palermo

Standup 03/03/2009

Joseph Palermo
Wednesday, March 4, 2009

Interesting Things

  • Somebody was seeing mongrels hang when using an older copy of the S3 gem. It turned out the older version had the option for persistent connections defaulting to true. Setting :persistent => false or using a newer version that has false as the default fixed their problem

  • One of our sites was seeing a unbalanced distribution of requests despite the fact that the load balancer was evenly distributing connections. One host typically had 2x the traffic of the others, and it would switch every few hours to be a different host. It turned out to be the Google crawler, which uses a keepalive, getting stuck on a single host and making a lot of requests. The load balancer is only able to balance TCP connections, which Google is only using a single one of. The likely solution will be haproxy or something similar in front of the hosts to better distribute traffic.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Topics

  • agile (783)
  • rails (117)
  • testing (90)
  • ruby (86)
  • ruby on rails (71)
  • jobs (62)
  • javascript (59)
  • techtalk (44)
  • ironblogger (42)
  • rspec (39)
  • bloggerdome (34)
  • productivity (34)
  • activerecord (30)
  • rubymine (30)
  • git (29)
  • gogaruco (29)
  • nyc (27)
  • design (24)
  • mobile (23)
  • pivotal tracker (22)
  • process (21)
  • cucumber (21)
  • jasmine (19)
  • ios (18)
  • tracker ecosystem (17)
  • webos (17)
  • objective-c (17)
  • fun (16)
  • android (16)
  • palm (16)
  • ci (16)
  • "soft" ware (16)
  • bdd (15)
  • tdd (15)
  • cedar (15)
  • rails3 (14)
  • performance (14)
  • css (14)
  • gem (13)
  • mouse-free development (12)
  • selenium (12)
  • goruco (12)
  • bundler (12)
  • api (12)
  • keyboard (11)
  • meetup (11)
  • railsconf (11)
  • nyc-standup (11)
  • capybara (10)
  • mac (10)
Subscribe to agile Feed
  1. ←
  2. 1
  3. ...
  4. 52
  5. 53
  6. 54
  7. 55
  8. 56
  9. 57
  10. 58
  11. ...
  12. 79
  13. →
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Tools
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >