I'm trying to test specific features that require certain app states, like a user having three pending orders. This often leads me to create one-off scripts or deal with massive seed files. I'm curious about how others tackle this issue in 2025. When you need a specific state, what methods do you use to create or reset it? Do you prefer using factories, snapshots, or raw SQL/ORM scripts? How do you maintain a modular and versioned seed process across your team? Who in your team manages these seeds, like QA, design, or product? Has anyone tried tools like Snaplet or other branching methods?
2 Answers
I usually write tests with an in-memory database for speed, then run them on the actual database as well. It’s super handy—I can export and import different datasets from acceptance or production to my dev environment. Plus, since my dev setup is virtual, I can use checkpoints to revert my machine to previous states, which makes preparing demos really straightforward!
For client-side applications that are highly interactive, I prefer using Storybook to write stories for my components, keeping them separate from the main app. This way, I can mock the data I pass into these components and test different scenarios, like empty states or when there's a lot of content. If my components make network requests, I add MSW handlers to simulate those, though it's a bit more complex. I also like to write tests based on these stories to catch any issues early on.
So are you still using mock data? Do you keep that in a shared folder to reuse it for seeding purposes?
That sounds like a solid workflow! What tool do you use for that?