Jonathan Linowes wrote: > > On Sep 5, 2008, at 11:50 AM, Ashley Moran wrote: > >> >> On 4 Sep 2008, at 18:55, Jonathan Linowes wrote: >> >>> I'm just thinking out loud here... >>> It could be useful to have a way to run scenarios on a copy of a >>> fully populated production database, as an alternative to normal use. >>> Not sure how that'd work, maybe replace the Given's but leave the >>> Whens and Thens? >> >> Hi Jonathan >> >> Every time someone asks me this my answer is always the same... >> >> Don't. Determine what class of issue is being exposed by your >> production database, distil it into suitable stories and specs, fix >> the code (migrating as necessary), then deploy to a staging >> environment running off a recent production backup DB. >> >> Trying to run tests against production database risks blurring the >> line between the well specified behaviour of your app and the pile of >> crap users inevitably fill it with. IMHO. >> >> Ashley > > thanks, i agree. I probably would not use it to diagnose a problem. > Rather to ferret out any problems I might not know about. > That is, if my stories run with my well controlled, relatively small > setups, I'd like to ensure they run on a large, fully populated, > somewhat 'random' set of real data. >
What you are describing sounds a lot like fuzzing... Have you checked out tarantula yet? http://blog.thinkrelevance.com/2008/2/26/tarantula-vs-your-rails-app -Ben _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
