Hacker News Reader

Comment by fro0116 | Hacker News Reader

I'd personally be interested in some details on how they're _generating_ the mock data for their server.

As they're using that mock data for testing, the data returned has to be deterministic, so I'm guessing they're either making up mock data manually by hard-coding that data in resolvers on the mock server implementation, or using some kind of fake-data generating library to generate that data dynamically based on graphql type in the schema, with a fixed seed so that the data doesn't change between runs.

I'm hoping to explore the latter approach a bit more as I feel it would be great for testing productivity to have mock data generated from the schema instead of having to manually write them for every new thing added.

View on HN

It's actually neither. :)

We have a shared development environment with a persistent (and thus deterministic) dataset. So when one developer runs a query against that dataset, another developer could run the same query and get the same result.

The best thing about this, of course, is that if your Storybook data looks at listing 112358, you can also open that same listing in development and see the same result in the product. Very powerful.

Thank you for the quick reply!

My question was more about how that persistent dataset in your shared development environment is created though. As that dataset has to first exist for people to query against it.

Curious if that creation process is manual or automated somehow through inference on the types in the schema.

For sure. Unrelated to GraphQL in this case. Very manual (in a good way!). Sometimes it's achieved manually via the UI. Sometimes manually via scripts, etc. Imagine you're creating a new field for Business Travel, and you've added some new fields via the API. One way or another you're grabbing 1-2 listings in development, modifying those listings to reflect the desired change, and then in the dev setup, you're saying "grab listings x and y and update their data for use in Storybook and unit tests."

In my experience, if the system is working properly, there's not a lot of room for type-driven inference. We often get a design with very explicit data present, and we want to bring that data in rather than calling on Casual or

Thanks! Yeah that approach makes a lot of sense for the use cases presented in the post, and may be the most pragmatic path for enabling this workflow.

Although I feel the automated data generation approach still has value in that it can introduce some variance in the dataset to better represent real-world data, potentially uncovering issues in handling of edge cases in the design/implementation of the UI, that the original conveniently customized dataset that came with the design wouldn't. Though such an approach will likely also need to offer the ability for users to override/customize the generated data on a case by case basis in order to be useful for real world applications, so we'll probably end up with a bit of a hybrid approach at the end of the day regardless.

Very cool! Is the shared dev environment read-only? (Or is it not a concern that one dev with write access might accidentally corrupt the data for the others?)

Reply on news.ycombinator.com