I heard about gems like faker or populator but they are a little bit old (populator does not seem to play well with Rails 3).
So my question is, what do you use to generate fixtures ?
If you are interested in new fixture framework for ruby, take a look on Fabrication. It's looks like FactoryGirl Rails but have more interested features. We are using it with Faker and it's fine. I think it's the best solution nowadays :)
Most people use FactoryGirl Rails, which works nicely with Faker for doing things like random names, to make test data during their tests.
If sometimes you just want to populate your Dev DB with some fake data to make your application work, you can still use FactoryGirl Rails and make a Rake task that will populate some data you need.
Related
I'm working on an existing app with a test suite based on vanilla Rails fixtures and MiniTest. Switching to FactoryGirl or the like is not an option.
I'd like to find a relatively complex open source Rails app to learn more about best practices with using fixtures. Any suggestions?
Take a look at https://github.com/Shopify/active_merchant, it also uses some fixtures
I've discovered Faker for myself, what is important:
It creates unique data every time while seeding database.
In some cases it does matter and better than same data. So, it is suitable for fixtures only;-)
It has handy templates for most cases e.g. phone.
You can check example in GitLab repo.
Where should I put test data that is for RSpec testing purposes only?
Like many things in life, it depends.
If you're using fixtures, they live in test/fixtures.
If you're using factory_girl with RSpec, it can read from a number
of places but spec/factories/*.rb seems the most sensible
place to put them.
If you're using something else, check the documentation for your
other fixture or factory gem.
You can use fixtures (1) if the data is simple or go to factory_girl_rails gem (2) if you need something more sophisticated.
Also you can create a rake task for populating your database.
Please consider look for similar questions like this
I am using Ruby on Rails 3.2.2, cucumber-rails-1.3.0 and rspec-rails-2.8.1. Since I have some "system" data stored in the database, and since I would like to test my application that needs that data in order to properly work, I would like to seed the test database before to run Cucumber features.
How can I make that? What do you advice about?
Rails has a feature called Fixtures which prepopulates the test database before testing. Fixtures uses YAML to seed a table of the same name with data.
The Ruby on Rails guides have a low down on fixtures that may be beneficial to have a look at.
Thare is also FactoryGirl.
It can read from any place but generally uses features/factories.rb or features/factories/*.rb
See RailsCast 275. Ryan uses it with RSpec, but the principles are the same. Note FactoryGirl has had a major revision since then, so all the API has evolved.
I like the factory_girl approach in tests, but one thing I'm a little unclear on is what to do about development data.
Usually with fixtures we had some dummy users, models etc in development. Then in tests we can create more on the fly or reference the existing ones but every developer had the same data in dev.
What's the common way to create development data with factory_girl? I saw rake db:seed but this looks like it's intended to be used in production also, so not quite the same thing.
I generally create fake data using Factories inside seeds.rb.
I just prepend the code with if Rails.env.development?
MongoDB has two popular ORMs for Rails: MongoID and MongoMapper.
Are there CouchDB ORM:s for Rails 3?
I can't say for sure since I've never used it, but it looks like CouchRest would be the way to go - specifically "CouchRest Model" looks like has been updated to work with Rails3 ActiveModel.
FWIW, I landed on CouchRest after finding this thread.
there is couchRest as noted above, or if you like active record style try couch_foo. I had different needs when i was looking into couch this past spring, and using rails 3. Rails 3 should be ORM agnostic, so it shouldn't really mess with it, although I couldn't get testing to work easily, but that could have just been me.