Newbie questions - Best practice for loading local db data and model tests? (factory_girl , debuggin

I’m pretty much a newbie with Rails and RSpec. I’m trying to follow best
practices as I start to work on my own Rails side project.

I’m using: rspec 2.1.0 / Rails 3.0.1 / ruby 1.9.2

  1. Currently I have a Rake task that I run that populates the local
    db by using Rails models directly. Is this an ok approach to load simple
    local data so your app is in a state for using it while developing? eg
    10.times do |x|
    u =…)!

  2. Is there a way I can just have my rspec tests run off the local
    sqlite db
    populated from my rake task? or is this a bad practice? I currently have
    messed around some using factory_girl factories and I can generate
    everything using the factories and use them in my rspec model tests, but
    this seems like I’m doing double the work - I’m loading things in my
    file and then again similar things are loaded with my factories? - maybe
    solution is to leverage the factory_girl factories to also populate my
    db with a rake task?
    What is the preferred approach for setting this kind of stuff up so your
    application has local data for working with and also for testing your

  3. Is there any way to use log/put statements to help in debugging
    within an
    rspec test so that I can run a single test and see what’s going on
    in the console?

(I’m finding it difficult to find a lot of this documentation in one
If all of the above kind of questions are easily covered in David’s
pragmatic rspec book, then I’ll just go get the electronic version.)


  1. Rails provides db/seeds.rb and the “db:seed” rake task specifically
    for this. See: #179 Seed Data - RailsCasts
    2. Yep, this is bad and will lead to slow, brittle specs. The RSpec
    talks about the importance of isolation and all that Good Stuff.
    3. The Rails logger is available to you:
    Debugging Rails Applications — Ruby on Rails Guides
    Keep in mind, you could just set an expectation on whatever you wanted
    “log”, and see what happens to it in the spec output.