4 ms·
Having your test database mirror production as closely as possible is also an important habit, however I’m biased since that’s part of the offering that I’m bui
by pistoriusp 3y ago
Having your test database mirror production as closely as possible is also an important habit, however I’m biased since that’s part of the offering that I’m building.
- e12e 3y agoYou might want to try and maintain a synthetic dataset for testing and staging that has the same "shape" as your production data - to avoid exposing sensitive data. We're currently trying to have each rails model implement a #new_example method that builds a valid subgraph filled in by Faker, ready to save. Ie a user = User.new_example will come with a Company.new_example if every user needs a company relationship. Still early, we'll see how it goes.
- pistoriusp 3y agoWe're doing the same, but for the TypeScript world with "Snaplet Seed." We use generative AI to generate deterministic values + the required relational data: https://www.snaplet.dev/seed https://www.snaplet.dev/seed We generate data based off of your database schema and your production data (if you give us access.) Since you've kinda already built something like this I would be curious to hear what you think!
- bdcravens 3y agoWouldn't it be easier to do the same with FactoryBot? It'll similarly cascade creation of associated records.
- e12e 3y agoI don't enjoy documenting the graph in two places, first in models, then in factories. But yes, the pattern is essentially the same, just our example methods and Faker - without Factory Bot.
- bdcravens 3y agoI can understand that. I prefer keeping my models clean without environment-specific implementation details, which is why I've settled on the FactoryBot approach for testing, seeding, etc.