How I like to set up application seeders

I've seen several different ways that teams use seeders in their Laravel apps. Today, I want to share the approach I find the most useful.

First, we have the typical DatabaseSeeder class as the entry point for all seeding.

But then instead of putting all the other seeders in this class, maybe wrapped in a bunch of if statements, we instead first do an environment check and then defer to a top-level seeder for the specific environment.

Honestly, this is how simple the typical seeder looks like in our projects:

if (App::environment(['local', 'staging'])) {
    $this->call(DevDataSeeder::class);
}

The name of this seeder indicates what it is being used for: It only exists to give us a bunch of fake data to work with as we manually click around our application.

But notice that we don't seed in production, and we don't seed in tests. Why not?

This could be a whole separate series of tips, but the short overview is:

1. We use migrations for system-level data that needs to exist in production
2. We like tests to start with a clean view of the world, and we create the data needed in each test.

But even if your project is currently using seeders in production and testing, this clean top-level approach is a great way to organize your seeders.

Here to help,

Joel

P.S. Do you want to get started testing, but feel stuck? Book a free community pairing session and let's write your first test together.