On Oct 25, 2007, at 12:40 AM, David C. wrote:
Only for DBs that support it. And it would add quite a bit of
complexity to rspec I think.
This is not really the intent of before(:all). It is more akin to
TestCaseSetup in xUnit - i.e. a class level method that doesn’t share
state w/ the examples. So you might have some load script to get the
DB into a known state before(:all), and then run each example in a
transaction so it rolls back to that known state. I think that’s how
rails does it but I’d have to peruse the code to verify that.
Yeah, that’s my guess, too.
Accessing fixtures in before(:all) is something you can’t do right now
because before(:all) is not running in the same scope as the examples
are - in fact, it runs before fixtures are loaded.
I’m still a little confused about fixture loading. Isn’t the test
database populated with fixtures when running rake db:test:prepare?
Even if we changed
that, you still wouldn’t want to access them before each, because
you’d be keeping a handle on objects whose underlying data are getting
rolled back after each example. Talk about unexpected
Well, we aren’t using fixtures, but instead using the
FixtureReplacement plugin (I’d be interested in your feedback, David,
or anyone else, for that matter).
I’m a little worried that the plugin is a little too good (for
readability, and for easy of writing tests): My coworker, who is new
to rspec, would rather hit the database in controller specs than mock
database access out.
Anyway, the situation was that he was hitting the database by
inserting 40 records per test case. Of course the thing came to a
screeching halt, and he changed the before(:each) block to a before
(:all). The tests in that description didn’t fail, but other ones
did (because some of the records were still hanging around).
Although the strangest thing was that running rake spec didn’t fail
the tests, but running them by hand did (and the same with Autotest).