Use Factory Girl's build_stubbed for a Faster Test Suite

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 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.

classOrderProcessordefinitialize(order,credit_card)@order=order@credit_card=credit_cardenddefprocesscharge_successful?charge_customerendprivatedefcharge_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 idenddefcharge_customer# runs Braintree::Customer.sale() with the appropriate optionsendend

None of this code hits the database. This allows us to write tests like:

describeOrderProcessordolet(: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'dobeforedoMockBraintree.stub_successful_customer_sale(transaction_id: transaction_id)endit'assigns the transaction id to the order'dosubject.processorder.transaction_id.should==transaction_idendit'returns true for #process'dosubject.process.shouldbeendit'does not assign any errors to the credit card'dosubject.processcredit_card.errors.shouldbe_emptyendendcontext'when the Braintree result is invalid'dobeforedoMockBraintree.stub_unsuccessful_customer_saleendit'does not assign the transaction id to the order'dosubject.processorder.transaction_id.shouldbe_nilendit'returns false for #process'dosubject.process.should_notbeendit'assigns errors to the credit card'dosubject.processcredit_card.errors.should_notbe_emptyendendend

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.

If you enjoyed this post, you might also like:

Want to level up your testing game?
Learn about testing Rails applications and TDD
in our new book
Testing Rails.
The book covers each type of test in depth,
intermediate testing concepts,
and anti-patterns that trip up even intermediate developers.