In suspenders, we have a rake task called dev:prime that allows us to seed
the database with information. We’re often asked why we prefer a custom task
over using rake db:seed which is already built into Rails. Let’s talk about a
few of the differences.
rake db:seed
We reserve the db:seed tasks specifically for data that must be present for
your application to function in any environment. One example of this may be a
list of US States in your database that your address form relies on. That data
should always exist, whether the app is being used in development or production.
rake dev:prime
Working on an app is easier if you have data that looks and feels similar to what your users see. If you’re new to the codebase or new to a specific feature having data preloaded that makes sense and sets you up for the feature, is really helpful.
Our development seeds contain data that are necessary for users to view most of the features of the app. They’re very convenient for developers or designers who are running the app locally. If you were building a multi user blogging application, your seeds file would likely generate the following:
- an admin user
- 2-3 normal users
- enough posts to ensure you have pagination. Most likely you’d want to space out their published date enough that you could also test the features to view posts by month or year
- 5-10 comments on each post with various authors including anonymous authors
- 2-3 deleted posts
As you’re building a new feature, if it requires special data to setup, put it
directly into the seeds file instead of adding it with the web interface or the
console. For example, if you’re building a feature to make sure that posts
without a published_at value are not visible on the homepage, add that to your
development seeds instead of creating one through the UI. This ensures that the
next person who needs to test that feature has it ready to go without as much
work.
How to generate data
For database seeds, we do not recommend using FactoryBot to generate your data. For generating data for your local development environment however, it can be very helpful to leverage your test factories to simplify setup. For building a lot of blog posts you could rely on the defaults for most fields but randomize a few key fields:
if Rails.env.development? || Rails.env.test?
require "factory_bot"
namespace :dev do
desc "Sample data for local development environment"
task prime: "db:setup" do
include FactoryBot::Syntax::Methods
titles = [
"You won't believe what we found out about cheese!",
"Don't skip these 12 super foods",
"Only 20s kids will remember these toys",
]
authors = [
"Liz",
"Sam Seaborn",
"The Honorable 3rd Duke of Long Names",
].map do |name|
create(:user, name: name)
end
50.times do
create(
:post,
author: authors.sample,
title: titles.sample,
published_at: (1..365).to_a.sample.days.ago,
).each do |post|
(1..10).to_a.sample.times do
create(:comment, post: post)
end
end
end
create_list(:post, 3, deleted_at: (1..10).to_.sample.days.ago)
end
end
end
It’s all about communication
Development seeds are another form of communication. Reading the tests can expose a great deal of information about an app and your development seeds can provide a similar benefit. If you treat them with care, they can provide a great way to onboard new teammates as well make feature development and bug fixes easier for your existing teammates.