Actually there is currently pre-loaded fixtures support but if you use it you lose the benefit of table_name(:fixture_name) accessors.
Basically the pre-loaded fixtures currently mean that rails does not load anything into the database it runs each test inside a transaction and then rolls the transaction back after the test has finished, this way the preloaded data stays the same in the database. I'm not actually proposing a mixed system, I'd just like a way to load the fixtures like they are currently loaded but do it once and only once for all tests. btw. Nested transactions would not necessarily be required for a mixed system, but you would have to reload the per-test fixtures after each transaction rollback. On E, 2007-07-23 at 08:20 -0700, Chris Cruft wrote: > 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 -~----------~----~----~----~------~----~------~--~---
