GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

shoulda 2.0

Posted by Dan Croak

Sep 30

Lots of shoulda news to report. The 2.0.x gem has been released, which includes bug fixes, new features, and deprecations.

Rails 2.1+ install

The gem is being hosted at github.com/thoughtbot/shoulda

1
2
3

Rails::Initializer.run do |config|
  config.gem 'thoughtbot-shoulda', :lib => 'shoulda/rails', :source => "http://gems.github.com"
end

1
2

rake gems:install
rake gems:unpack

Now 100% gem

Listen… if you’re still a plugin, I look at you (I’m looking at you, Paperclip), shake my head, and say, “So much untapped potential. Could’ve been big.”

Why gems?

• Ruby comes with a packaging system. No need for another, especially with the gem support in Rails 2.1.
• It’s nice to scan the vendor/gems listing and see version numbers.
• github has excellent gem support.
• In shoulda’s case, it’s a project that can be used in and out of Rails. It’s a pain to have both a plugin and a gem.

Ryan McGeary and Josh Nichols did the bulk of this conversion and related refactoring. They deserve extra acclaim because they’ve made it easier for everyone to contribute to shoulda.

Improvements to current macros

should_assign_to :user, :equals => "@user"

should_assign_to :user, :class => User

should_have_one :address, :dependent => :destroy

ActiveRecord::Errors.default_error_messages is used instead of home-brewed regexes for all Active Record macros.

New Macros

1
2
3
4
5
6
7
8

context "Creating a post"
  setup { Post.create }
  should_change "Post.count", :by => 1
end

# :from and :to examples
should_change "Post.count", :from => 0, :to => 1
should_change "@post.title", :from => "old", :to => "new"

1
2
3
4

context "Updating a post"
  setup { @post.update_attributes(:title => "new") }
  should_not_change "Post.count"
end

should_filter_params :password, :ssn

1
2
3

should_render_with_layout # defaults to application 
should_render_with_layout 'special'
should_render_without_layout

1
2
3
4

should_route :get, "/posts", :controller => :posts, :action => :index
should_route :delete, "/posts/1", :action => :destroy, :id => 1
should_route :get, "/users/1/posts/1", 
  :action => :show, :id => 1, :user_id => 1

1
2
3

should_respond_with_content_type 'application/rss+xml'
should_respond_with_content_type :rss
should_respond_with_content_type /rss/

should_return_from_session :user_id, "@user.id"

Before statements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class UserControllerTest < Test::Unit::TestCase
  context "the index action" do
    setup do
      @users = [Factory(:user)]
      User.stubs(:find).returns(@users)
    end

    context "on GET" do
      setup { get :index }

      should_respond_with :success

      # runs before "get :index"
      before_should "find all users" do
        User.expects(:find).with(:all).returns(@users)
      end
    end
  end
end

Automatically load custom macros

Writing custom macros is a common practice for The Modern Shoulda Developer. For example, should_have_attached_file used to be a handy custom macro to have around when you’re using Paperclip.

There were a few problems with that, however. Where should that macro go? RAILS_ROOT/test/test_helper.rb? Why do we have the same macro in multiple apps for the same plugin?

Enter the new shoulda_macros directory. Shoulda will automatically load custom macros she finds in:

• RAILS_ROOT/test/shoulda_macros
• RAILS_ROOT/vendor/gems/#{gem_name}/shoulda_macros
• RAILS_ROOT/vendor/plugins/#{plugin_name}/shoulda_macros

Now, every Paperclip user can use the latest should_have_attached_file because it is where it belongs.

should_be_restful is being deprecated

should_be_restful will be removed in a future release. It is currently in a grace period where you’ll see a warning during your test runs. It will be added to the new woulda gem if you care to keep using it. Its problems:

• It dissuades the programmer from good TDD practice. It’s working at too high level of abstraction and encourages the programmer to take too many big steps.
• It is an attempt to be like Rails scaffolding, which is a good way to learn REST, but the syntax is so cryptic it doesn’t accomplish that goal.
• It’s near impossible to find the line in your test file that is actually failing or erroring.
• You have no idea how many tests it generates or how they’re implemented, which lulls the programmer into a false sense of security.

Removed

• load_all_fixtures (use fixtures :all instead)
• shoulda.conf and color support (use the redgreen gem instead)

Credit

Ryan McGeary, Matt Jankowski, Mike Boone, Tammer Saleh, Josh Nichols, Joe Ferris, Keith Morrison, Me