Add ability to generate fake data for Dev env's #275
Conversation
In order to make the fake data more realistic: - resolved_at and relief_at must be after the creation date of the case - Each fake account should have multiple fake cases - Each fake engineer should have multiple fake cases
|
@dcritch now we need to install the Faker package to run our tests. It's kind of big (2MB), let me know if you can see a way for us to avoid installing it. |
|
Are you concerned about the linter.yml or the install when firing up a dev env via docker-compose? For the workflow, I don't think we have much choice. For dev environments: is there a risk to having the package installed in prod? |
Talking more about linter.yml. For dev environments it's not necessarily a risk, I'm thinking that the package might be unnecessary bloat |
|
Yeah. How about using the package once to generate some data, then add them to the repo in a json file or something as a fixture? |
|
I think this is the best solution. Then we could add the code in the |
…utils into fake_data
|
@dcritch Now dev env's will pull fake data from a JSON rather than generating it dynamically. I've also add the data generation code as a standalone CLI, so new fake data can be generated if desired. Faker has also been removed from our dependencies. |
|
nice, looks great! faker seems pretty neat! thanks for pulling this together. I'll merge, but we might want to include an doc update on using it as well |
overwrite_cacheistruefake_data,overwrite_cache, andnumber_of_casescan be defined as env var's or via cli (flask init-cache --fake-data --overwrite-cache --number-of-cases=123)One shortcoming is that multiple cases aren't created for accounts, ie every account only has one case. So we'll need to generate the accounts first, then generate multiple cases for each fake account. In any case, I figured I'd make a PR as a starting point.
TODO: