This blog article argues whether database seeding should make the application look as if ordinary users have already been using it, in contrast to showcasing edge cases and test suits. While seed scripts in reality can be used to accomplish both the argument is not that seed data can never support testing but instead that one development dataset should not be filled with every technical edge case.

1. Introduction

When developing an application the developer doesn’t want to repeat the process or creating a user, then listing a product, sending messages, and so on just to be able to test a new feature they are working on. Manually creating records in the database wastes time especially if it has to be done frequently. A seed script solves this issue so the developer doesn’t have to start from zero every time. How ever seeds can also hinder development if it gets bloated with testing every single scenario possible with potential technical non-realistic naming, missing fields and placeholders. What should a useful development seed actually contain?

2. Seed data and test data serve different purposes

First of all, database seeding means to populate a database with initial records after its structure has been created (Supabase). Seeds may include reference data like roles, categories, or settings. It provides a constant and reproduceable sample dataset for development. I can also provide a prepared environment to conduct specific tests. This blog post differentiates two main use cases for seed data.

Development Demo Data
First development demo data’s aim is to produce a regular environment for manual use of the application. It makes the application understandable and useable out of the box. These are really only used in local development to hep with developing or demonstrating features.

Test Fixtures
These are created for specific scenarios that are aimed at smaller parts of the application. The seed data contains only the required states for the given test. This isolates areas of the application and uses less time and processing power because its meant to be dropped often (playwright).

3. Properties of useful development seed data

How unrealistic seed data hurts development
The realism behind the data that is seeded into the database has high significance when finalizing or demonstrating features. Technical labels and placeholders can make or break the UI. A poor seed can create presentation problems, development, and usability problems. To try and avoid these watch out for the following properties.

a. Believable visible content
Names, titles and descriptions are all textual information that need to look natural and follow the application. Other data such as prices with currencies and dates should be reasonable. Images also play a major role and are not an easy thing to make realistic. Finally one of the most important factor is not to use user-facing fields for storing developer notes or technical naming.

b. Relationships
Filling out the table row by row is not best practice to make the data look realistic. A solution for this is to create a few users and create connected records around a few scenarios demonstrating complete workflows.

c. Representativeness
Make sure that all major features of the application are represented in the seed data. This doesn’t have to cover every single possibility, but allow the developer to see functioning features.

d. Safe information
One might ask why not just use production data if available? There are many cases where that is the solution to diagnose a bug for build a highly specific feature. The issue is the handling of personal information. Ideally when using production data a different script should be used to anonymize the data. Even if that is the case real data has to be used with extra care and may add difficulty and require more time when developing, hence the safest option is to use invented but realistic looking data.

4. Conclusion

I decided to choose this topic because i encountered database seeding in multiple development environments before and I have always thought that I would do it a bit differently. Then I started my own project that had seeding for the first time fully controlled by myself. I experienced both ends of the scale either putting too many scenarios and potential edge cases in the seed data or lacking the ability to instantly test some feature. Finally I believe multiple seeding scripts are ideal and a middle point has to be found between maintenance requirement and usefulness due to the size some seeds can grow to.

References

https://www.prisma.io/docs/orm/v7/prisma-migrate/workflows/seeding

https://supabase.com/docs/guides/local-development/seeding-your-database

https://playwright.dev/docs/test-fixtures