Thanks for posting your specdoc, Brandon -- they''re a great example. On 11/21/06, Brandon Keepers <bkeepers at gmail.com> wrote:> > A user purchasing items > - should create an order > - should add to the user''s orders > - should create line items > - should set line item amount to the item''s price > - should set line item amount to 0 if item does not have a priceHowever, I''ve found myself now naming the specs themselves without the "should" language, thinking that the spec body is where the should stuff goes. I like how the specdoc reads more confidently without it -- the spec doc says, "this is the way things are" rather than "this is kinda sorta maybe how the system works (if there are no bugs)". context "A user purchasing items" do specify "creates an order" do @user.complete_purchase.should_be_instance_of Order end # ... end It''s just a matter of taste in the end, I suppose, but is there a recommended practice for naming specs? Cheers, /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/5b9031f4/attachment.html
On 11/21/06, Nick Sieger <nicksieger at gmail.com> wrote:> Thanks for posting your specdoc, Brandon -- they''re a great example. > > On 11/21/06, Brandon Keepers <bkeepers at gmail.com > wrote: > > > > A user purchasing items > > - should create an order > > - should add to the user''s orders > > - should create line items > > - should set line item amount to the item''s price > > - should set line item amount to 0 if item does not have a price > > However, I''ve found myself now naming the specs themselves without the > "should" language, thinking that the spec body is where the should stuff > goes. I like how the specdoc reads more confidently without it -- the spec > doc says, "this is the way things are" rather than "this is kinda sorta > maybe how the system works (if there are no bugs)". > > context "A user purchasing items" do > specify "creates an order" do > @user.complete_purchase.should_be_instance_of Order > end > # ... > end > > It''s just a matter of taste in the end, I suppose, but is there a > recommended practice for naming specs?When you look at the specs what you propose makes sense, however when you read the output I think using "should" in the names helps to convey the "spec-ness" of the specs. To me.
On Nov 21, 2006, at 9:01 AM, Nick Sieger wrote:> It''s just a matter of taste in the end, I suppose, but is there a > recommended practice for naming specs?I use "should" simply because it''s easier. That''s the mindset I''m in when I''m writing them. I also think that it reenforces the idea that it is a specification, and not simply a test.> Cheers, > /NickBrandon
On 11/21/06, David Chelimsky <dchelimsky at gmail.com> wrote:> > When you look at the specs what you propose makes sense, however when > you read the output I think using "should" in the names helps to > convey the "spec-ness" of the specs. To me.This got me thinking about RFC-2119 recommended language for requirement levels [1]. This would obviously be a big change in direction for RSpec, but what if: object.must == value # => required; produces error object.should == value # => recommended; produces warning object.may == value # => informational message that an optional feature is not provided Of course, the utility of this is questionable for RSpec. It might be interesting for a tool (not RSpec, but something like it) that''s essentially a portable specification language that can be applied to more than one implementation. But now we''re not really talking about BDD, so forgive me for straying OT. Cheers, /Nick [1]: http://tools.ietf.org/html/rfc2119 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/7c601bf4/attachment.html
I''m not sure if that would really work with RSpec - the way I see it, when you say a behaviour is *optional*, what you really mean is that that behaviour only happens under certain circumstances (i.e. a particular context). Of course this is already handled by setting specifications under certain contexts. Within a particular context a behaviour either happens or it doesn''t, I don''t think there should be any middle ground. Ultimately we are only concerned with what WILL happen under certain contexts, not things that may or may not happen (which is an observation at a level higher than we are working on). Cheers Luke> object.must == value # => required; produces error > object.should == value # => recommended; produces warning > object.may == value # => informational message that an optional > feature is not provided > > Of course, the utility of this is questionable for RSpec. It might > be interesting for a tool (not RSpec, but something like it) that''s > essentially a portable specification language that can be applied > to more than one implementation. But now we''re not really talking > about BDD, so forgive me for straying OT. > > Cheers, > /Nick > > [1]: http://tools.ietf.org/html/rfc2119 > _______________________________________________ > 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/20061121/55376f21/attachment-0001.html
I agree with Luke. If you say something "may" happen, you
haven''t
asserted any constraints on your program behavior. Unless I
misunderstand how this was intended. Consider this artificial example:
context "the weather" do
specify "it should be a gray day (or is that a grey day)" do
the_sky.should_be :cloudy
the_ground.may_be :wet
the_ground.may_be :snowy
end
end
What do the last two test tell us? Will the specs be demonstrably
implemented or not as a result of them? As I said, I''m a newbie at
this, but it makes more sense to me to state this:
context "the weather" do
specify "it should be a gray day (or is that a grey day)" do
the_sky.should_be :cloudy
end
specify "it should be raining" do
the_ground.should_be :wet
end
specify "it should be snowing" do
the_ground.may_be :snowy
end
end
Is that too verbose?
Steve
On Nov 21, 2006, at 9:06 AM, Luke Redpath wrote:
> I''m not sure if that would really work with RSpec - the way I see
> it, when you say a behaviour is *optional*, what you really mean
> is that that behaviour only happens under certain circumstances
> (i.e. a particular context). Of course this is already handled by
> setting specifications under certain contexts. Within a particular
> context a behaviour either happens or it doesn''t, I don''t
think
> there should be any middle ground. Ultimately we are only concerned
> with what WILL happen under certain contexts, not things that may
> or may not happen (which is an observation at a level higher than
> we are working on).
>
> Cheers
> Luke
>
>> object.must == value # => required; produces error
>> object.should == value # => recommended; produces warning
>> object.may == value # => informational message that an optional
>> feature is not provided
>>
>> Of course, the utility of this is questionable for RSpec. It
>> might be interesting for a tool (not RSpec, but something like it)
>> that''s essentially a portable specification language that can
be
>> applied to more than one implementation. But now we''re not
really
>> talking about BDD, so forgive me for straying OT.
>>
>> Cheers,
>> /Nick
>>
>> [1]: http://tools.ietf.org/html/rfc2119
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> 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/20061121/fcb245e0/attachment.html
On 11/21/06, Luke Redpath <contact at lukeredpath.co.uk> wrote:> > I''m not sure if that would really work with RSpec - the way I see it, when > you say a behaviour is *optional*, what you really mean is that that > behaviour only happens under certain circumstances (i.e. a particular > context). Of course this is already handled by setting specifications under > certain contexts. Within a particular context a behaviour either happens or > it doesn''t, I don''t think there should be any middle ground. Ultimately we > are only concerned with what WILL happen under certain contexts, not things > that may or may not happen (which is an observation at a level higher than > we are working on). >Agree, which is why I think this type of feature doesn''t make sense for BDD, where you''re using the specs to drive the implementation. You are writing the specs and the code, so you know exactly how the code "should" behave. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/1721b43a/attachment.html