Greetings all.
I''m looking over a ''greenfield'' pasture, and enjoying
the TDD(BDD)
process of creation.
I''m currently rspec''ing a finite state machine
(acts_as_state_machine). As such, I need to persist the model through
''specifies'' within the context - from top to bottom.
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!"
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 ?
Thanx to the core team and contributors for rspec. The "diameter of
my smile" is wide.
Cheers,
Jodi
General Partner
The nNovation Group inc.
www.nnovation.ca/blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070124/f3e7c934/attachment.html
On 1/24/07, Jodi Showers <jodi at nnovation.ca> wrote:> > Greetings all. > I''m looking over a ''greenfield'' pasture, and enjoying the TDD(BDD) process > of creation. >Consider yourself lucky!!!> I''m currently rspec''ing a finite state machine (acts_as_state_machine). As > such, I need to persist the model through ''specifies'' within the context - > from top to bottom. > > 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. Thanx to the core team and contributors for rspec. The "diameter of my> smile" is wide. >Thanks for the feedback. David Cheers,> Jodi > General Partner > The nNovation Group inc. > www.nnovation.ca/blog > [image: ranting o the technology and business of software]<http://feeds.feedburner.com/on-innovation> > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070124/fd12f76e/attachment.html
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