Want to speed up your test suite? Reduce the number of objects persisted to
the database. With Factory Girl, this is really easy; instead of using build
or create to instantiate your models with data, use build_stubbed!
build_stubbed is the younger, more hip sibling to build; it instantiates
and assigns attributes just like build, but that’s where the similarities
end. It makes objects look look like they’ve been persisted, creates
associations with the build_stubbed strategy (whereas build still uses
create), and stubs out a handful of methods that interact with the database
and raises if you call them. This leads to much faster tests and reduces your
test dependency on a database.
For example, let’s say we have an OrderProcessor that accepts instances of
Order and CreditCard. It hits the Braintree API and returns a boolean
value for if the charge actually happened.
class OrderProcessor
def initialize(order, credit_card)
@order = order
@credit_card = credit_card
end
def process
charge_successful? charge_customer
end
private
def charge_successful?(result)
# processes the result to determine if the result is valid,
# operating on the order and credit_card instance variables to
# add errors, send emails, or track Braintree's transaction id
end
def charge_customer
# runs Braintree::Customer.sale() with the appropriate options
end
end
None of this code hits the database. This allows us to write tests like:
describe OrderProcessor do
let(:transaction_id) { '1234' }
let(:order) { build_stubbed(:order) }
let(:credit_card) { build_stubbed(:credit_card) }
subject { OrderProcessor.new(order, credit_card) }
context 'when the Braintree result is valid' do
before do
MockBraintree.stub_successful_customer_sale(transaction_id: transaction_id)
end
it 'assigns the transaction id to the order' do
subject.process
order.transaction_id.should == transaction_id
end
it 'returns true for #process' do
subject.process.should be
end
it 'does not assign any errors to the credit card' do
subject.process
credit_card.errors.should be_empty
end
end
context 'when the Braintree result is invalid' do
before do
MockBraintree.stub_unsuccessful_customer_sale
end
it 'does not assign the transaction id to the order' do
subject.process
order.transaction_id.should be_nil
end
it 'returns false for #process' do
subject.process.should_not be
end
it 'assigns errors to the credit card' do
subject.process
credit_card.errors.should_not be_empty
end
end
end
Instead of creating twelve different records (at the minimum - if any of these factories have associations, you introduce more multipliers), we create none. This keeps the spec blazing fast.
Properly factored code should be small and concise. Code should typically depend
less on the state of the data in relation to the database and more on its
state in relation to other objects. In the above example, OrderProcessor
only handles dealing with Braintree and dealing with its errors; it does not
care about how this data is displayed to the user. That’s left for the
integration tests, which should be hitting the database.
Although it’s not useful in every situation (there are cases where you’ll want
data to exist, like when you’re testing uniqueness constraints or scopes),
build_stubbed should be your go-to FactoryGirl method over build or
create. Everyone running your test suite (yes, even yourself) will thank you.

Recently, we implemented a feature that required a before_filter in ApplicationController and whitelisting some other controllers using skip_before_filter.
We couldn’t actually test something like this directly because callbacks aren’t really methods. They’re entirely used for their side effects so we can only test what happens when we invoke one. Let’s check out an example:
require 'test_helper'
class ApplicationControllerTest < ActionController::TestCase
context 'ensure_manually_set_password' do
setup do
class ::TestingController < ApplicationController
def hello
render :nothing => true
end
end
ActionController::Routing::Routes.draw do |map|
map.hello '', :controller => 'testing', :action => 'hello'
end
end
teardown do
Object.send(:remove_const, :TestingController)
end
context 'when user is logged in' do
setup do
@controller = TestingController.new
end
context 'and user has not manually set their password' do
setup do
@user = Factory(:user, :manually_set_password => false)
login_as @user
get :hello
end
should 'redirect user to set their password' do
assert_redirected_to new_password_path(@user.password_token)
end
end
end
end
end
Note the use of the double-colon prepended to the TestingController, which ensures the class is top-level, not an inner class of ApplicationControllerTest. That way we can just do :controller => 'testing' and not have to write :controller =>
'application_controller_test/testing'. We also use the private method remove_const to remove the class after we’re done, so we don’t litter the namespace.
Is there a bundle command to tell me what would be updated with bundle update, without actually making those updates?
As it turns out there is! Bundler 1.1 introduces a new command:
bundle outdated
Show all of the outdated gems in the current bundle.
This will give you a report of gems that have newer versions available.
By itself, this will list all of the gems in your Gemfile.lock that have newer versions, and what the current and latest versions are.
This gives a good preview of what you are up against if you want to get your gems up to date. From there, use git commits to make incremental changes.
Today I created an app with the suspenders gem, and noticed it is running on Rails 3.1.1, which I wanted to upgrade to 3.2.2.
I also saw a few other gems with version attributes:
gem 'sass-rails', '~> 3.1.4'
gem 'coffee-rails', '~> 3.1.1'
gem 'uglifier', '>= 1.0.3'
gem 'rspec-rails', '~> 2.6.1'
gem 'cucumber-rails', '1.1.0'
gem 'capybara-webkit', '~> 0.7.1'
First I ran rake to confirm all tests were passing, bundle update to make sure the gems were all up to date with the versions specified, and created an initial commit.
Next I upgraded to rails 3.2.2 and reran bundle update, and found out (after a couple itterations) that sass-rails and coffee-rails had to be updated too, because of there dependance on ActiveSomethingOrOther. Updating these three gems to their latest versions allowed bundle update to do it’s thing.
I reran my tests, and did ran git diff Gemfile.lock to see exactly what was new. For giggles I reran bundle outdated and rejoiced at the shrinking list. Time to commit with a message about the gem version changes.
From here it was rinse and repeat, checking rubygems.org and looking at the dependencies, making small changes, bundling, raking, committing.
At the end of the road I had a good series of commits spelling out exactly what was needed to get to my goal of a fully updated rails 3.2.2 environment.
If you run bundleoutdated and all you see is:
Outdated gems included in the bundle:
* sprockets (2.4.0 > 2.1.2)
Then you are doing it right!
Read more about what’s new with bundler 1.1 from Pat Shaughnessy.
The new version of your favorite file upload library, Paperclip 3.0.0, has been released earlier today. We changed a lot of internals to make Paperclip better. These changes lay the groundwork for the shiny, new features that will come in the future.
Ruby 1.8.7 and Ruby on Rails 2.3.x are both reaching end of life now, so this is a good time to drop support for them. This let us remove some code and introduce a new validator syntax (below.)
If you’re still using Ruby on Rails 2.3.x or Ruby 1.8.7, you should lock Paperclip to version 2.x by doing this:
gem "paperclip", "~> 2.7"
In some rare case that there’s a critical bug in Paperclip 2.7.x, we’ll release a patch version under that minor version. However, you’re advised to upgrade to a newer version of Ruby and Rails as soon as you can.
We’re working to extract functionality into modules. We’re not done with this yet, and it is an ongoing process. If you’ve freedom patched Paperclip, you’ll need to look out for this as some of the methods might have new names or locations.
If you are developing a plugin for Paperclip—e.g. custom storage, a processor, or a validator—we would love to hear from you. We want to expose hooks to help you develop your plugin and reduce the risk of breaking things in the future.
When you’re installing the new version of Paperclip, you’ll be greeted with this upgrading message:
##################################################
# NOTE FOR UPGRADING FROM PRE-3.0 VERSION #
##################################################
Paperclip 3.0 introduces a non-backward compatible change in your attachment
path. This will help to prevent attachment name clashes when you have
multiple attachments with the same name. If you didn't alter your
attachment's path and are using Paperclip's default, you'll have to add
`:path` and `:url` to your `has_attached_file` definition. For example:
has_attached_file :avatar,
:path => ":rails_root/public/system/:attachment/:id/:style/:filename",
:url => "/system/:attachment/:id/:style/:filename"
Going forward, the default URL for your attachment will be /system/:class/:attachment/:id_partition/:style/:filename. This will prevent filename collisions and will reduce the number of files in a single directory.
All of the validators have been rewritten to take the full advantage of Rails 3. They’re now in their own Validator class, and can be passed into validates or validates_with like any other Active Model validator:
validates :avatar, :attachment_presence => true
validates_with AttachmentPresenceValidator, :attributes => :avatar
We are also introducing a validates_attachment method. This method is almost the same as the validates method except you can skip the :attachment_ prefix. We’ve found this helpful when defining multiple validators on a single attachment:
validates_attachment :avatar, :presence => true,
:content_type => { :content_type => "image/jpg" },
:size => { :in => 0..10.kilobytes }
I would like to thank our contributors and all of the other users who are helping to make Paperclip better and better. Please give this new version a try. If you find a bug, please file an issue, or better, you can also help us fixing it.
We’re thrilled to introduce the new Paperclip, and we hope that you’ll like them.