Yes...but. The current pre-loaded fixtures support depends on manual database loading. I was hoping you were proposing a more active role for Rails: before every test run, load a named set of fixtures. The selection of those fixtures needs to be in a separate file (something like test/fixtures.rb or such). Perhaps one file per test type (unit, functional, integration) would be appropriate.
In any case, such a mechanism would allow one to factor out some of the common fixtures used across all test scenarios. Hopefully there would be a performance gain -In my case, many fixtures would be loaded one time only (and restored by rolling back the DB). And by making the definition of these global fixtures a ruby script, you could perhaps open the door to some more programmatic and sophisticated fixture management scenarios including foreign key management, dynamic fixtures (beyond ERB) and fixtures copied from production. On Jul 23, 11:50 am, Tarmo Tänav <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
