Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
2072 New seed data for testing #3209
We need more and better structured sample data for dev testing and to bootstrap staging data. This pull request introduces a new rake task that aims to replace openfoodnetwork:dev:sample_data.
The generated data is mainly the data defined in https://docs.google.com/document/d/1_va0Aw2yJ5BRe-HtuBT-OC8HNHIui0gvQ0uElWjDVs0. There are the following differences:
I tried to keep this as short as possible, but I spent 22 hours on this already. I made some effort though to make it easier to maintain and extend. It has much better code metrics than the old code.
What should we test?
This cannot be staged without a developers help. The developer needs to run the following to make this data active:
sudo /bin/systemctl stop delayed_job_openfoodnetwork.service sudo /bin/systemctl stop unicorn_openfoodnetwork.service mkdir -p db/backup/ pg_dump -h localhost -U ofn_user openfoodnetwork | gzip > db/backup/staging-`date +%Y%m%d%H%M%S`-before-reset.sql.gz bundle exec rake db:reset openfoodnetwork:sample_data sudo /bin/systemctl start delayed_job_openfoodnetwork.service sudo /bin/systemctl start unicorn_openfoodnetwork.service
Testers can then verify that the data is set up as specified. I think, @myriamboure worked on the data with certain test scenarios in mind. Would you like to share these so that we can verify that they work with this data?
Changed: Added and improved sample data for testing and demo instances.
Changelog Category: Changed
How is this related to the Spree upgrade?
Some of the data generation may have to be updated for the Spree upgrade.
left a comment
Hey, amazing @mkllnk , let's go forward and iterate on top of this.
As I see these factories, I wonder if we should use the factories in spec/factories here or adapt spec/factories to be used here. If we do that our automated acceptance tests will look familiar to everyone.
btw, the code climate warnings should be easy fixes.
I wondered the same. There is some potential code duplication here. But I didn't use those factories for two reasons:
While generating sample data and spec data are similar tasks, I don't like to tie the two together. I like to specify everything explicitly and design the factories to be used as easily as possible for our sample data. The old task used the spec factories, but I don't think it made it better.
One lesson from reading these factories is that our data structures are badly complex. Working on the models to make the factories easier would also reduce the potential of bugs a lot.
Thanks @mkllnk ! I need to dive again into it which is not easy ;-)
Then you created duplicates, as I created those two profiles to make sure we distinguish how they look like on the map if needed (4 is in white color for instance as distributor and not using the shopfront). Actually there are differences between a producer and a shop profile.
But anyway, it might not harm...
I don't think you will be able to checkout without a VAT zone setup in configuration... don't you think ? If it's not a problem then no problem we can iterate. But we definitely do want to test that VAT is properly calculated, and VAT reports display correctly, etc. So we would need it to avoid to recreate VAT categories and rates in config each time we want to test some VAT potential impact of a PR.
The second hub distributor was setup to test inventories. As it's OC is sourcing info from inventory and not from product catalog, and this hub (Maryna hub) is the only one to use the inventory feature.
Anyway, I'll write some test scenarios at the end of the document, will do it now ! Cheers :-)
Ok so I wrote at the end of the document the cases I had in mind when writing this document (it has been reviewed by Sally at that time...) https://docs.google.com/document/d/1_va0Aw2yJ5BRe-HtuBT-OC8HNHIui0gvQ0uElWjDVs0/edit so I guess in order to test we should somehow test that the different cases are setup as expected ? Please check @mkllnk that it's what you understood, as with the changes you made I think some of those test cases are not setup then. But anyway, we can test and see if that's ok as you did it to start with, and iterate.
Okay, I think we used different terminology. I thought a profile is an enterprise that is not a producer and sells none. That's how the shops page lists them. A profile has no connection to any products. They just have a name, image, description and so on.
From your scenarios I understand that a producer profile is what we just call a producer. They can actively manage their produce which can be sold through other enterprises.
I see four different icons on the map. And I think this is what they mean:
So the tractor symbol indicates the producer property and the colour red indicates selling.
In my data I created Penny Profile. That is probably matching what you describe for Mary's Physical Shop. I called her Penny, because for OFN it doesn't matter if it's a physical shop, a physical farm or just a public produce swap room. It's only a profile using the OFN as directory, not as shop or producer. But now I see how you thought of it as a shop profile, because the symbol on the map is the same. I don't thing that was the intention though.
I thought so. I just wanted to get some feedback after working on this for such a long time. I will add VAT.
I created an inventory for 5-“Maryel hub”. Does it matter which hub is using the inventory?
That shop also has two order cycles and one is shared with the private shop 7-Maryse-hub. I skipped the first sub-distributor, but I can add it to distinguish between VAT and no VAT.
referenced this pull request
Dec 20, 2018
This suggestion isn't strictly necessary, but: if we're creating enterprises with different configurations and relationships, can we describe it in each enterprise's profile description so that any dev or tester can click on them under /shops and see an explanation, like "This shop sells it's own produce, and supplies Enterprise X", or "This is a hub that stocks products from Enterprise Y and inventory from Enterprise Z"?
@mkllnk I guess we can start with what you have done, when testing I suggest we carefully document then / adapt the use cases I describe to the reality of what you have done. If we realize there are important cases missing we will comment when testing. Let's move forward.
left a comment
This should be split into multiple files. I also marked a few places that I think were overlooked and bang methods should be used.
Aside from those, looks great!
left a comment
Thank you for the suggestions @sauloperez. I learned a lot. I incorporated more of the feedback and since it's all approved now, I rebased it as well.
I didn't go for named parameters, because that would have been a lot of redundancy. But maybe we will do it in another iteration.