[rspec-users] hello! first post + context_setup
Jodi Showers
jodi at nnovation.ca
Wed Jan 24 20:52:28 EST 2007
On 24-Jan-07, at 3:03 PM, David Chelimsky wrote:
> I have bumped into a couple of probs:
> 1. context_setup to define the doesn't permit access to fixtures.
> "You have a nil object when you didn't expect it!"
>
> Please submit a bug on this to the tracker:
>
> http://rubyforge.org/tracker/?group_id=797
>
> 2. transactions are defined around each specify? For this
> reason my specifies are very repetitive, encompassing all state
> movement for all previous contexts.
> 3. since 2 seems to be the case, it probably doesn't matter
> - but is execution order guaranteed for specifiy's ?
>
> 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.
>
> 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.
>
> 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.
>
> So I'd recommend just writing one spec block.
>
I'm in agreement David.
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.
I'll file that bug tomorrow.
Jodi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070124/19b46816/attachment-0001.html
More information about the rspec-users
mailing list