> I like that idea. Since most people just run all tests inside a big
> transaction anyway, there should rarely be changes to the fixtures or
> the database. Keeping those stable when that's the case would be
> great.
The approach that's working for us really well right now:
1. Make a "fixtures or DB changed!" checksum and stash it. I'm using a
sorted list of the full paths and mtimes of test/fixtures/**/*.yml,
plus the mtime of schema.rb (since it's regenerated any time a
migration runs).
1a. (there's a db:fixtures:reset task to kill this stash)
2. Regenerate and compare checksums on every test run. Different?
Reload all fixtures: we're not specifying subsets anywhere. Same? No
load necessary.
Preloading/change tracking like this has made autotest viable again,
which has been pretty awesome.
> But we certainly should think about the transaction case. It's quite
> valuable to be able to test transactions. So perhaps we can have a
> special block or something that you could wrap around your test if it
> uses transactions and make sure that all pre- and post-cleanup is
> done. It'll make that one test run slowly, but that's fine.
isolate_fixtures(:optional, :list, :of, :fixtures) do
def test_something_involving_transactions
# ...
end
end
Something like that?
~ j.
--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
