Tarmo's proposal of having two classes of fixtures (pre-loaded before all tests, and per-test fixtures) seems very smart. It would also ease the transition from the current per-test approach.
For performance reasons, wouldn't such an approach require nested transactions? Not that nested transaction support is a bad thing... As for dailer's and other's proposal of reworking the guts of fixture loading into a single transaction -PLEASE! I could really use the foreign key help that provides. On Jul 22, 3:02 pm, Tarmo Tänav <[EMAIL PROTECTED]> wrote: > On E, 2007-07-23 at 05:51 +1200, Michael Koziarski wrote: > > > > > > Right now, the fixture-scenarios plugin is a step in the right > > > direction, but I wouldn't mid joining in in an effort to replace the > > > current Fixture system in rails completely, hell, I wouldn't mind it > > > breaking backwards-incompatibility if thats what it took. > > > Increasing the overhead required for editing fixtures never seemed > > like a good idea to me. I've always used fixtures as a way to store a > > 'representative' snapshots of my production system, and made my tests > > work accordingly. In this kind of usage the per-testcase fixtures > > overhead isn't needed as you can simply load the test database right > > at the beginning, and rollback the transaction after each testcase. > > > The fixtures code is currently ripe for some tidying, but I'm not > > necessarily sold that they're more harm than good. The ability to > > get a named reference to a particular chunk of a known object graph, > > is completely killer. > > What I think could be useful is a middle-road between pre-loaded > fixtures and transactional fixtures, so the fixtures are loaded at the > beginning of tests and not reloaded for each testcase which is wasted > work if the fixtures are not specified per-testcase and transactional > fixtures are used. > > I'm currently using something like this, I specify all fixtures in > test_helper.rb and I monkeypatched the fixtures loading code so that > it never reloads the same fixtures when transactional fixtures are used. > (@@already_loaded_fixtures in my hack is shared by all test classes) > > This gets increasingly more useful as the amount of fixtures grows > and the amount of testcases (TestCase classes) grows. Sure, it may > not be the best idea to use the database for unit tests but I find > it quite comfortable to be able to use the same fixtures for both > development and testing. > > I also had to wrap the load_fixtures method into a transaction that > deffers constraints so the fixtures can be loaded in whatever order > without getting FK errors as long as all the FK constraints are > satisfied when all the fixtures are loaded. > > Besides that I hacked the transaction code (I'm using the nested > transactions plugin) so that transactions inside a transactional test > work exactly like they do in a normal test. (I'll reopen #5457 for > a discussion on this) > > Any comments, suggestions on this? Could some of this get into core? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
