Rake Tasks: db:seed vs. dev:prime

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 U.S. 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 FactoryGirl 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_girl"

  namespace :dev do
    desc "Sample data for local development environment"
    task prime: "db:setup" do
      include FactoryGirl::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.