Creating Test Data for Rails Apps

I wrote a guest post over at 3 Weeks to Live on our progress in building data sets for testing OnCompare under Ruby on Rails.

The biggest challenge has been generating a large number of records, but I think we can do that with loops and factory_girl:

The other place to use large data is to stress test the system. … I need to know that the algorithm will continue to be responsive when we have 300 products. At this point, I’m looking at running loops around factory_girl calls so that it will generate most of the non-essential information. [Settings] up a single product matrix may take a dozen records, but I can loop over that 300 times and factory_girl will automatically create records with new names (using the sequence method shown in the factory definitions above).

before do
  category = Factory.create(:category)
  300.times do
    product = Factory.create(:product, :category => category)
    12.times do
      Factory.create(:question, :category => category, :product => product)
    end
  end
end

As a follow-up, we also added Faker to our gem set, which has a ton of handy methods for mocking up data. So, for example, I can set up a factory definition with Faker::Lorem.words(3) for the name or description of a product and 300 products will all look different. It’s pretty sweet.

OnCompare: Can we build a company in three weeks?

So, I’m in the middle of an interesting experiment. A group of guys I know invited me to join them for a 3-week run to try to build a technology company. That means software, market and customer base in three weeks. The product we’re working on, OnCompare, will allow you to rank and find on-line services, based on the most critical criteria for the class of service. For example, looking at email services you could decide whether templates are important or whether you need survey support. Because we’re doing this in three-weeks, we also decided to blog the whole thing so that the process is (mostly) transparent.

My role, along with entrepreneurial advisor, is straight dev work right now. But I am evaluating this as a technology tool, because I see this kind of rapid prototype practice happen in events but rarely within companies. After attending some 8-hour Startup events several years ago I wanted to try stopping our consulting company for a day to run the whole company on a single project. From a consulting perpective this could be a huge differentiator: while large projects take a while, slipping them a day is no big deal; but if a potential client can be sold with, “we’ll get something up and running by the end of the week” that could be the closer. We never got to do it while I was there because (a) we never had a potential client that needed that and (b) we didn’t have unanimous support, which I felt we had to have.

Do you think this whole-team/company sprint idea (e.g. 8-hour Startup, Startup Weekend, Hackathons, etc.) can be integrated into your company (Facebook tried it)? Clearly there’s desire for it among developers. Can that be supported and used to develop new ideas, to break the monotony of the daily drudgery?

My colleague Ruben Ortega wrote Why do Software Developers Tolerate “Crunch Time”? last summer for the Communications of the ACM, which sparked a deep conversation about this topic. Sometimes we want the herculean effort to feel like we’ve accomplished something. But does a full-team sprint like this produce something you can put into production?

Most of these events are focused technical accomplishments (engineering, some testing, graphics). I recognize that customer development is a long-running process but clearly you either have an idea to start testing or a market demand to try to fit when you start this event. Do you think that marketing and (some) customer development can happen in a short time too? While three-weeks is much longer than a weekend or a hackathon, we’re testing whether it is long enough to build a customer base.