Railsters:
For various reasons, not worth discussing here, we’d really prefer to
load fixtures like this:
class MySuite < etc::TestCase
def setup
fixtures :posts, :forums, :whatnots
end
…
end
Does anyone know how to call the same thing fixtures calls, and how to
put it inside the setup?
What are the reasons? Oh, okay…
deep breath<
We have a very project with various Rails 1.2 and 2.1 applications
using elaborate test fixtures that roughly correspond to established
databases with hundreds of thousands of records. We have many Abstract
Tests, and many of our cases have very elaborate setups. We are trying
to start using test-spec, and we already use scenario-fixtures.
To clean up our testage, we would like to use test-spec like this
(warning - pseudo-Ruby):
context ‘generic’ do
fixtures :posts, :forums, :whatnots
setup{ foo }
specify ‘foo things’ { foo things}
specify ‘more foo things’ { more foo things}
context 'specific' do
setup{ bar }
specify 'bar things' { foo & bar things}
specify 'more bar things' { etc}
end
end
The point (the only point of BDD I can detect so far) is (at the
possible risk of less AbstractTest flexibility), we can inherit setups
without the (faint) burden of excessive modules and ‘include’ lines.
However, my feeb experiments with test-spec show that setup{bar}
cannot see the outer context’s fixtures. This is either pilot error,
or it is unprincipled and counterintuitive. Ideally, the fixtures
should inherit and accumulate as one descends deeper into nested
contexts.
Next, fixture_scenarios seems to throw an exception if we get too
creative with the nested setups and fixtures. We will eventually go in
after that issue.
So the easiest short-term fix to all this fun would appear to be using
setups to, uh, set each test case up, the way certain industry thought-
leaders intended. Putting fixtures() at class scope is syntactic
sugar, and our tests can only get so sweet.
–
Phlip