<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On 24-Jan-07, at 3:03 PM, David Chelimsky wrote:</DIV><BLOCKQUOTE type="cite"><DIV><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><DIV style=""><DIV>I have bumped into a couple of probs:</DIV><DIV><SPAN style="white-space: pre;">        </SPAN>1. context_setup to define the doesn't permit access to fixtures. "You have a nil object when you didn't expect it!" </DIV></DIV></BLOCKQUOTE><DIV><BR>Please submit a bug on this to the tracker:<BR><BR><A href="http://rubyforge.org/tracker/?group_id=797">http://rubyforge.org/tracker/?group_id=797</A> <BR></DIV><BR></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><DIV style=""><DIV>        2. transactions are defined around each specify? For this reason my specifies are very repetitive, encompassing all state movement for all previous contexts.</DIV><DIV>        3. since 2 seems to be the case, it probably doesn't matter - but is execution order  guaranteed for specifiy's ?  </DIV></DIV></BLOCKQUOTE><DIV><BR>Order is not guaranteed as in a commitment from the RSpec team to keep it that way. We believe that each specify block should be completely independent from the next, so order should not be related. <BR><BR>That said, the specify method generates a Specification object which is added to a Ruby Array held by the Context object (which is generated by the context method). Given that implementation, the specs will run in order. And it is HIGHLY unlikely that this would ever change. Depending on that, however, is a risk that you would have to understand and choose to take. <BR><BR>Thinking about the particular problem at hand, imagine that we solved the transaction problem and allowed you to declare the entire context to be wrapped in a single transaction and guaranteed order. Now if spec 1 fails, you can't really trust the outcome of spec 2 (because it depends on state leftover from spec 1). This seems to me to be no different than having a single specify block that takes you through all the states. In fact, it strikes me as worse than the single spec block because you can't trust the other outcomes. <BR><BR>So I'd recommend just writing one spec block.<BR><BR></DIV></DIV></BLOCKQUOTE><BR></DIV><DIV>I'm in agreement David. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm facing a bunch of code duplication (that doesn't feel safe), so I'd perhaps I'll work out a means to iterate over the events and expected states.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'll file that bug tomorrow.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Jodi</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR></BODY></HTML>