Dev database and test fixtures

[joemasilotti]

Hey folks, I want to get feedback from other contributors before I dive into something. In working on #237 it has become clear that our local database seeds leave a lot to be desired. The issue has been hidden from me because I usually use a production dump when working locally.

Ideally, running bin/setup will get your local environment set up in a way that it looks and feels like production. There are multiple developers with full profiles, businesses with active subscriptions, and conversations with notifications all set up. This gives a developer a much better idea of how the full system works – and enables easy account switching to test other workflows. For example, [email protected] can test messaging developers while [email protected] can test the /admin portion of the site.

So, my question is: how we should manage our database seeds? Some ideas:

1. More manual seeds

Redo db/seeds.rb to add a bunch more developers with fleshed out profiles. Add businesses in different parts of the onboarding flow. Add notifications, conversations, and messages.

The upside is that this will be very close to what production looks like. The downside is the maintenance burden of making sure the seeds are always working. (Maybe we can automate that?)

2. Dummy seeds

The other end of the spectrum is to use faker (or similar) to create a ton of bogus looking seeds. This still requires the maintenance burden of making sure everything works correctly but does enable us to skip the manual entry of lots of text.

3. Load test fixtures

Another idea is to load the test fixtures into the development database via rake db:fixtures:load. The upside is we already have a ton of seeds for our testing and it might force us to clean up our fixtures (they all read a little mundane). The downside is that it would blur the line between what a test fixture seed data are. If we want something just for local dev we would need to add a test fixture, which feels wrong.

4. Load production

This is a non-starter. I'm not interested in anonymizing/pruning production data for development.

---

So, dear maintainer, which do you prefer? Or is there something else that works in your project that you'd like to see implemented here? I'd love to hear what you're thinking!

[joemasilotti]

PR #312 handles this!

I ended up going with a mix of 1. and 2. There are now a small handful of maintainable, manual seeds along with 20 random seeds. Also, CI will run the seeds to ensure no commit breaks them moving forward.