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:> 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.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> --Thank you, > --R.J. Ekim
> > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110817/c0124d5e/attachment.html>
On Wed, Aug 10, 2011 at 2:23 AM, Mike Jr <n00spam at comcast.net> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20110817/0b4ef2a6/attachment.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 http://blog.sidu.in On 10 August 2011 04:53, Mike Jr <n00spam at comcast.net> wrote:> 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 > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >