A few tips when creating factories with FactoryBot (formally FactoryGirl).
For most DB-backed models in your system, you will want to create a “base” factory. It is what you will generally use when you need an instance of a model but don’t generally care about the data (other than the data you supply).
The factory should be named after the object you are creating it for. If your object is named
Order then your “base” factory should be named
order. Your “base” factory should use the following rules:
- Provide the minimum values necessary to be able to save a valid instance.
- Optional fields or fields with default values are not generally provided.
belongs_toassociations should be provided assuming they are required (the default in Rails)
has_and_belongs_to_manyrecords are required for your object to function you may need to populate those, but you should try to avoid your object having that sort of dependency.
Anytime you need a value in a factory it is best to use a realistic but always changing value. For example, if I wanted to provide the age of a user I wouldn’t hard-code it to
18. I would use
(1..110).to_a.sample. This would make it pick a random value between 1 and 110 each time I get an instance of that factory.
The reason for using changing values is to ensure your tests don’t happen to pass due to some chance value. Each time you run your test you are introducing a bit of randomness to ferret out issues that may depend on certain values.
Locate Important Values in Tests
If the value in an object is important for making the test pass, it should be initialized in the test. This helps to prevent your factories from becoming brittle. You want to avoid the situation where changing a factory in trivial ways breaks tests.
For example, if you have a
full_name method on your
User object that you are testing which combines your
last_name your tests should look like:
it 'returns first and last name combined' do
user = create :user, first_name: 'Jane', last_name: 'Doe'
expect( user.full_name ).to eq 'Jane Doe'
With the above, your tests will not fail regardless of how your factory is configured for
last_name. While you could have fixed values of
Doe in the factory and not have to provide them in your test, specifying the values in the test reduces the fragility of your test suite.
If creating an object with your desired attributes is too complicated to do inline, create a specialized factory but make sure the factory name indicates it has the state you want. For example your “base” factory for your
Order object probably won’t have line items, but some tests need a complete order. A realistic complete order does have at least one line item as well as other info (payment, shipping, etc). In this case you probably want to make a factory called
complete_order that gives you a realistic completed order.
By naming it
completed_order the implied attributes and related records associated with that name do not make the factory fragile as the name becomes a contract between the test and the factory.
Avoid Factory Proliferation
It can be tempting to create a child factory for every possible type of object you might need. For example, you might initially think to have your “base”
user factory choose a random valid permission level. But then create other factories for each role (
Instead, avoid creating a sub-factory for setting trivial attributes. If you can do
create :user, role: 'admin' just as easy in your test do that instead. It might require a few extra characters but:
- It keeps your factories more manageable
- It makes it clear just by looking at the test what you are doing without having to go look up what
Even for a more complex factory type if you are only using it in the scope of one test file perhaps you can just place it in a RSpec