As I understand it, RSpec runs in two passes. The first pass reads
your code and invokes factory methods to generate instances of example-
group and example subclasses. The second pass then invokes these
generated instance to run your test.
RSpec filters (via RSpec.configure) are set and operate during the
first pass. The determination if a particular describe or it block is
to be skipped is determined before the first test is executed in the
second pass. Even if I were to use a lambda in the filter (see
http://blog.davidchelimsky.net/2010/06/14/filtering-examples-in-rspec-2/
) this would execute in the first pass.
This is well and good. Why generate test code that will be skipped?
But a sophisticated test will make decisions in mid test. If a
certain test condition occurs, set a singleton hash and then have
later tests condition their processing on that hash. In my tests,
these if statements are within the it blocks so that they execute
during the second pass.
It sure would be less clutter if the describe and it statements
supported a filter that is evaluated in the second pass.
Or have I missed some existing feature? (Oh please be true!)
–Thank you,
–R.J. Ekim
On Aug 9, 2011, at 6:23 PM, Mike Jr wrote:
) this would execute in the first pass.
This is well and good. Why generate test code that will be skipped?
But a sophisticated test will make decisions in mid test. If a
certain test condition occurs, set a singleton hash and then have
later tests condition their processing on that hash.
RSpec is built around the premise that each example is run in its own
environment, and that one should not depend on the outcome of another.
This is not unique to RSpec, btw. It’s how all of the unit testing
frameworks of which I am aware work.
In my tests,
these if statements are within the it blocks so that they execute
during the second pass.
It sure would be less clutter if the describe and it statements
supported a filter that is evaluated in the second pass.
Or have I missed some existing feature? (Oh please be true!)
Nope. You have not missed something. You’re just trying to put a square
peg into a round hole.
Cheers,
David
RSpec is built around the premise that each example is run in its own
environment, and that one should not depend on the outcome of another. This
is not unique to RSpec, btw. It’s how all of the unit testing frameworks of
which I am aware work.
I know I’m going off-topic, but TestNG supports that. You can say that
one
tests depends on another and use the second one to both set up the
fixture
and assert behavior. But I don’t like it either, since it smells of
Fragile
Test.
On Wed, Aug 10, 2011 at 2:23 AM, Mike Jr [email protected] wrote:
But a sophisticated test will make decisions in mid test. If a
certain test condition occurs, set a singleton hash and then have
later tests condition their processing on that hash. In my tests,
these if statements are within the it blocks so that they execute
during the second pass.
It sure would be less clutter if the describe and it statements
supported a filter that is evaluated in the second pass.
I am not sure if I understand you, but if I do, conventional wisdom
suggests
that having if statements in your tests is a very bad idea. You might
want
to check out this article:
http://xunitpatterns.com/Conditional%20Test%20Logic.html
But a sophisticated test will make decisions in mid test.
Quis custodiet ipsos custodes? You’ll need to write specs for the
logic in your specs then.
Best,
Sidu.
http://c42.in