"Mark Wilden" <[EMAIL PROTECTED]> writes: > Just to be clear, these methods of truncating tables or remembering rows to > delete are only useful in the presence of fixtures? Otherwise, the standard > transactional support is sufficient and (probably) faster, right? (if for no > other reason because it's all handled deep in the bowels of the db).
Truncating tables would be good if you're using fixtures only some of the time. For example, you've got two example groups, one using fixtures and the other one not. In the one that uses fixtures, you shouldn't truncate the tables (or at least not the tables for the fixtures you're loading - Rails will handle that automatically), but in the example group that doesn't use fixtures, you do want to clear the table so that you have a known state. Another case where truncating tables would be beneficial is when your application code makes use of an explicit transaction. Postgres/MySQL/sqlite don't support nested transactions, so you wouldn't be able to spec your code as you want (Oracle does have nested transactions though). As far as transactional fixtures being faster than truncating...I would have thought so, but evidently my colleague said he found his specs ran FASTER with truncated tables. The flip side is, I heard that they tried turning that off and enabling transactional fixtures, and a bunch of specs broke unexpectedly...so that technique isn't foolproof. Please keep in mind I've never actually tried it, I've only talked to a guy who talked to the guy who has :) Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
