At Laracon AU in 2018, David Hemphill gave a talk titled "Abusing Laravel for Fun and Profit" and one section of the talk I found interesting was on feature tests powered by database seeders:
David goes through some common ways to set up your data before testing, such as using a setUp method, a trait, and then he came around to using custom seeders in his tests.
One advantage to seeders is you can create them for specific cases and call $this->seed directly from your test instead of using factories all over. Like this example:
class WebhookTest extends TestCase { function setUp() { $this-›seed( 'UserwithTeamSeeder'); $this-›user = User :: first); $this-›team = Team:: first() ; } function test_a_user_can_create_a_webhook() { // Act //
Another advantage is that you can have isolated seeds to match specific scenarios. David gives the examples of:
UserWithValidApiKeyTeamWithExpiredBillingPlanOrganizationOverUsageLimitCreatorHasntFinishedSetupCustomerWithNovaLicense
This allows you to make them specific for complex test setups and is great for testing complex edge cases.
One final tip he mentions is you don't even have to keep these with your other seeders. In your composer.json, you can autoload these from somewhere else, like your tests directory:
"autoload-dev": { "psr-4": { "Tests\\": "tests/", "Tests\\Seeders\\": "tests/seeders" } },
Of course, like all things programming, this is just one way of doing tests with data. I've heard of others creating entire seeds with all the edge cases and lots of almost real-world data. Then only refreshing the db if they add a new migration.
If you are tired of writing lots of factories directly in your tests give this idea a try. You might like it.
