Why you should consider writing dev:prime rake task

Evgeny Sugakov

As a Rails developer you know `db:seed` rake command, it seeds some data to application’s DB. Usually, and it’s a good practice, `db:seed` contains data which is needed for the application to work.

But what if you need to set up the application for development or testing on staging environment? (I’m not talking about containers right now, they don’t solve this problem)
There are some options:
1. add more data to `db:seed`
2. load DB dump from a working application
3. add data manually

First option is a bad idea, because `db:seed` is needed for application settings or basic data for application operation.

Second option could be an answer and I’ve used it several times, but it’s only good when you have a proper dump. Also guys from the frontend might not be happy with strange console commands, when you ask them “to load the DB dump”. And you always have to have proper data in the dump, because if you take an old one, there might be collisions between dump’s data and a current db schema.

Of course manual data creation is a bad idea.

Here comes `dev:prime` rake task which generates test data for your application. There is a good article about it from thoughtbot, go ahead, read it, I’ll wait here :)

As it is pointed out in the article, it’s better to use FactoryGirl and Faker for test data generation. Here is another benefit of writing such a task: your test data will always be up to date. Moreover, some time later, if you need to remember which data should be used for specific models there will be a place where you can find it (rake task).

Using this task with different test data (for example: longer strings, or bigger images) can help with finding UI bugs. We’ve found a coupe of UI issues using this method, otherwise we could have faced it in production, which is not good.

It’s also a good idea to write a simple test for this rake task: create N records in DB, check that it was created. Of course this test will be slow, but you don’t have to run it everytime on a dev machine, add `CI` tag and run it only on CI twice a day (or more).

Another benefit of this task is that you can test connections between different models, for example, model validations: validations have changed and you’ve forgotten to test them — 500 in production.

The main idea behind this task is to have a tool which helps you to quickly bootstrap a project for presentation to show how it works, or for a new developer to quick-start with the application or for a designer to know how the design works in a real application.

Development and support of a big application is hard, let’s do it a little less painful with test data and quick bootstrap with `dev:prime` ☕️

Evgeny Sugakov

Written by

Software engineer. Current: RoR, Swift, Elixir, JS. Next: Haskell. http://macshifford.me

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade