--- luke saunders <[EMAIL PROTECTED]> wrote: > Ditching the database and then recreating it for each test is the > right thing to do in the general case since previous tests might have > dropped tables, deleted/created rows and so on which would affect > subsequent tests. I see from the article that you have a > static/dynamic split for your tables so that the static tables are > created once then left untouched for all tests, but when/how do you > refresh the dynamic ones?
It's simple. Each test fetches a schema object. That's when the dynamic tables are refreshed by truncating them. The fixtures are then loaded. This approach is not perfect, but the trade off was fantastic: we were able to actually use our test suite again. In practice, we've not actually had problems with this tactic. > I think the main thing is, if you find the ability of > DBIx::Class::Fixtures to specify what data should be included in each > fixture set desirable then you can just customise the rest to suit > your needs. I'll have to read through the docs more carefully. I didn't really understand them :) So is there no programmatic way of getting the SQL and bind params that DBIx::Class generates? We've needed this functionality a few times and not just for this. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/ _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
