Alright. Thanks Myron and Jon; you've answered my questions. On Monday, April 25, 2016 at 5:02:19 PM UTC-7, Myron Marston wrote: > > To expand on what Jon said: we offer random ordering as a way to surface > accidental ordering dependencies. It's not possible to offer random > ordering if the specs are executed as they are defined, because the order > they are defined is the same on every run of the suite. > > On Mon, Apr 25, 2016 at 4:36 PM, Jon Rowe <[email protected] > <javascript:>> wrote: > >> The “alternative” strategy you suggest isn’t really possible for us, but >> in it wouldn’t allow any kind of ordering other than “defined" >> >> Jon Rowe >> --------------------------- >> [email protected] <javascript:> >> jonrowe.co.uk >> >> On Tuesday, 26 April 2016 at 09:30, [email protected] <javascript:> >> wrote: >> >> Sorry, I think my reading comprehension was poor, as it seems you did >> answer this indirectly. >> >> OK, it looks like the "why" would then be to offer ordering and filtering >> functionality. Is this correct? >> >> I would assume (remember, *I'm* not expecting different behavior; some >> users are) the "alternative" would be that a test is executed *when it's >> encountered, *as opposed to "collecting" all the suites (or "groups", >> "describes", etc.) beforehand, then choosing which tests (or "specs", >> "examples", etc.) to run (and in what order). >> >> I'm going to guess that the "inclusion" filtering is not possible without >> using the current strategy, because the "alternative" strategy would not >> necessarily know that an "inclusion" filter was in use--until it was too >> late. >> >> How would the "alternative" strategy inhibit RSpec's ordering >> functionality, if at all? >> >> Thanks for helping me out. >> >> Chris >> >> On Monday, April 25, 2016 at 12:03:06 PM UTC-7, Myron Marston wrote: >> >> I tried to answer the "why" when I said: >> >> ...but for RSpec, we intentionally load all the specs first (which >> involves evaluating the `describe` blocks), then apply spec ordering, >> filtering, etc, and then run the specs (the `it` blocks). Thus, the `3` is >> printed first (as it got printed while specs were being defined) and then >> the specs ran and 1 and 2 are printed. >> >> >> If that doesn't answer your question, can you explain what order you >> would expect? The order RSpec operates in feels completely natural to me >> as it enables features like spec ordering, filtering, etc...but I've never >> really considered another ordering, so I'm not sure what order you have in >> mind that you are contrasting RSpec's ordering to. >> >> Myron >> >> On Mon, Apr 25, 2016 at 11:51 AM, <[email protected]> wrote: >> >> Gah, I screwed that up. No, Mocha works like how you're describing; 3 1 >> 2 would be the order. >> >> So, now that I've confirmed it works the same, my answer is "why"? >> >> >> On Thursday, April 21, 2016 at 10:12:58 AM UTC-7, Myron Marston wrote: >> >> Assuming I understand your pseudocode correctly, your example would be >> written like this: >> >> ``` ruby >> RSpec.describe "foo" do >> it "bar" do >> puts 1 >> end >> >> describe "baz" do >> it "quux" do >> puts 2 >> end >> >> puts 3 >> end >> end >> ``` >> >> This would print the numbers in the following order: >> >> 3 >> 1 >> 2 >> >> ...which, noticably, is different from the order of mocha. I can't >> comment on Mocha's design (having never used it) but for RSpec, we >> intentionally load all the specs first (which involves evaluating the >> `describe` blocks), then apply spec ordering, filtering, etc, and then run >> the specs (the `it` blocks). Thus, the `3` is printed first (as it got >> printed while specs were being defined) and then the specs ran and 1 and 2 >> are printed. >> >> HTH, >> Myron >> >> On Thu, Apr 21, 2016 at 9:50 AM, <[email protected]> wrote: >> >> Hi, >> >> I'm a current maintainer of Mocha <https://mochajs.org>, which (AFAIK) >> was inspired by RSpec. I am not the *author *of Mocha; the author is >> long gone, or I'd ask him about this. >> >> My question regards a paradigm which seems common to BDD-style test >> frameworks. I assume that RSpec works similarly, but I apologize if I'm >> incorrect. >> >> It's most easily illustrated with a pseudocode example (sorry, I'm >> unfamiliar with Ruby): >> >> begin suite 'foo' >> >> begin test 'bar' >> print 1 >> end test >> >> begin suite 'baz' >> >> begin test 'quux' >> print 2 >> end test >> >> print 3 >> >> end suite >> end suite >> >> >> In Mocha (and I assume RSpec), the following would be printed: >> >> 1 >> 3 >> 2 >> >> >> This is difficult for some users to reason about. I'm unable to explain >> what this algorithm buys us, other than perhaps better control over >> disabling tests and suites. Can anyone explain why it works as it does? >> >> thanks >> Chris >> >> -- >> You received this message because you are subscribed to the Google Groups >> "rspec" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rspec/872f0ecb-4ca1-4440-bb3f-27e111c80d89%40googlegroups.com >> >> <https://groups.google.com/d/msgid/rspec/872f0ecb-4ca1-4440-bb3f-27e111c80d89%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "rspec" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rspec/cdfe4dcd-aea0-43ef-84fe-64603aa2c64f%40googlegroups.com >> >> <https://groups.google.com/d/msgid/rspec/cdfe4dcd-aea0-43ef-84fe-64603aa2c64f%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "rspec" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] <javascript:> >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rspec/2bf301e8-19b0-41b2-8917-7957fed96df4%40googlegroups.com >> >> <https://groups.google.com/d/msgid/rspec/2bf301e8-19b0-41b2-8917-7957fed96df4%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "rspec" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] <javascript:> >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rspec/39AEAC5DB783416FBDBB2596BE3E1A13%40jonrowe.co.uk >> >> <https://groups.google.com/d/msgid/rspec/39AEAC5DB783416FBDBB2596BE3E1A13%40jonrowe.co.uk?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > >
-- You received this message because you are subscribed to the Google Groups "rspec" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/92224c40-aa42-4359-b2f9-8a354eeae750%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
