rspec users - Jul 2007 - "they" synonym for "it"?

I''ve noticed that I phrase a lot of shared behaviours in plural, eg

   describe "All payment_details views"

How about a "they" alias to "it" so you can write

   describe "All payment_details views", :shared => true do
     they "should have a card number field" do
       # ...
     end
   end

WDYT?

Ashley

On 7/11/07, Ashley Moran <work at ashleymoran.me.uk>
wrote:
> I''ve noticed that I phrase a lot of shared behaviours in plural,
eg
>
>    describe "All payment_details views"
>
> How about a "they" alias to "it" so you can write
>
>    describe "All payment_details views", :shared => true do
>      they "should have a card number field" do
>        # ...
>      end
>    end
>
> WDYT?
>
I''m a little worried that If we add this alias, people are going to
want umpteen other aliases like it_should etc.

It should be easy for you to just alias that method locally in your project

Aslak
> Ashley
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 7/11/07, aslak hellesoy <aslak.hellesoy at gmail.com>
wrote:
> On 7/11/07, Ashley Moran <work at ashleymoran.me.uk> wrote:
> > I''ve noticed that I phrase a lot of shared behaviours in
plural, eg
> >
> >    describe "All payment_details views"
> >
> > How about a "they" alias to "it" so you can write
> >
> >    describe "All payment_details views", :shared => true
do
> >      they "should have a card number field" do
> >        # ...
> >      end
> >    end
> >
> > WDYT?
> >
>
> I''m a little worried that If we add this alias, people are going
to
> want umpteen other aliases like it_should etc.
>
> It should be easy for you to just alias that method locally in your project
+1
We want to keep things simple.
>
> Aslak
>
> > Ashley
> >
> >
> > _______________________________________________
> > 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
>

On 11 Jul 2007, at 13:47, David Chelimsky wrote:
>> It should be easy for you to just alias that method locally in  
>> your project
>
> +1
> We want to keep things simple.

Fair point!

El 11/7/2007, a las 12:42, Ashley Moran escribi?:
> I''ve noticed that I phrase a lot of shared behaviours in plural,
eg
>
>    describe "All payment_details views"
>
> How about a "they" alias to "it" so you can write
>
>    describe "All payment_details views", :shared => true do
>      they "should have a card number field" do
>        # ...
>      end
>    end
>
> WDYT?
In a case like this, isn''t "All" the same as "any"
or even "a", or
even omitting the article entirely?

For example:

   describe ''Any payment_details view'' do
     it ''should have a card number field'' do
       ...

   describe ''A payment_details view'' do
     it ''should have a card number field'' do
       ...

   describe ''payment_details view'' do
     it ''should have a card number field'' do
       ...

   # or whatever the class is called
   describe PaymentDetailsView do
     it ''should have a card number field'' do
       ...

Cheers,
Wincent

On 7/11/07, Wincent Colaiuta <win at wincent.com>
wrote:
> El 11/7/2007, a las 12:42, Ashley Moran escribi?:
>
> > I''ve noticed that I phrase a lot of shared behaviours in
plural, eg
> >
> >    describe "All payment_details views"
> >
> > How about a "they" alias to "it" so you can write
> >
> >    describe "All payment_details views", :shared => true
do
> >      they "should have a card number field" do
> >        # ...
> >      end
> >    end
> >
> > WDYT?
>
> In a case like this, isn''t "All" the same as
"any" or even "a", or
> even omitting the article entirely?
>
> For example:
>
>    describe ''Any payment_details view'' do
>      it ''should have a card number field'' do
>        ...
>
>    describe ''A payment_details view'' do
>      it ''should have a card number field'' do
>        ...
>
>    describe ''payment_details view'' do
>      it ''should have a card number field'' do
>        ...
>
>    # or whatever the class is called
>    describe PaymentDetailsView do
>      it ''should have a card number field'' do
>        ...
Excellent point. I''m sure the code in each example would be dealing
with a single object, not all objects.
>
> Cheers,
> Wincent
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 11 Jul 2007, at 14:25, Wincent Colaiuta wrote:
> In a case like this, isn''t "All" the same as
"any" or even "a", or
> even omitting the article entirely?
Mmm, I noticed that myself not long after I posted lol.  I''ve already  
started rewording everything...

On 11 Jul 2007, at 14:29, David Chelimsky wrote:
> Excellent point. I''m sure the code in each example would be
dealing
> with a single object, not all objects.
We had a Polish guy start here last year (sadly poached by a company  
in London now).  When I showed him RSpec I told him the thing he  
would find hardest was not the spec code, it was the English involved  
in writing the descriptions.  Might be useful if I followed my own  
advice :)

> We had a Polish guy start here last year (sadly poached by a company
> in London now).  When I showed him RSpec I told him the thing he
> would find hardest was not the spec code, it was the English involved
> in writing the descriptions.  Might be useful if I followed my own
> advice :)
 Thats my biggest problem with rspec, (I''m a non english speaker
working in a German/English environment)  It would be great a guide or
a tips list to make our specs more  readebles, Something like 10
English tips to improve your specs readability ;)

-- 
-------------------------------------
Pedro Del Gallego

Email              :   pedro.delgallego at gmail.com

On 11 Jul 2007, at 15:00, Pedro Del Gallego wrote:
>  Thats my biggest problem with rspec, (I''m a non english speaker
> working in a German/English environment)  It would be great a guide or
> a tips list to make our specs more  readebles, Something like 10
> English tips to improve your specs readability ;)

Don''t think I can come up with 10 off the top of my head but I always  
told Pawel to follow the rule "phrase descriptions as GIVEN WHEN  
THEN".  There''s plenty of better examples on this list and
elsewhere,
but basically if I have an idea like this:

   A cow prodded with a stick should moo

I think:
   GIVEN="a cow", WHEN="prodded with a stick",
THEN="moo"

and turn it into this code:
   describe Cow do
     before(:each) do
       @cow = Cow.new
     end
     it ''should say "moo" when sent prod_with_stick''
do
       @cow.prod_with_stick.should == "moo"
     end
   end

It doesn''t apply rigidly to every situation, but 90% of the time, if  
I keep chanting GIVEN WHEN THEN I write clean, focussed specs.  The  
rest is mainly vocabulary (although sometimes it can be hard to  
phrase something clearly).

Ashley

On 7/11/07, Ashley Moran <work at ashleymoran.me.uk>
wrote:
>
> On 11 Jul 2007, at 15:00, Pedro Del Gallego wrote:
>
> >  Thats my biggest problem with rspec, (I''m a non english
speaker
> > working in a German/English environment)  It would be great a guide or
> > a tips list to make our specs more  readebles, Something like 10
> > English tips to improve your specs readability ;)
>
>
> Don''t think I can come up with 10 off the top of my head but I
always
> told Pawel to follow the rule "phrase descriptions as GIVEN WHEN
> THEN".  There''s plenty of better examples on this list and
elsewhere,
> but basically if I have an idea like this:
>
>    A cow prodded with a stick should moo
>
> I think:
>    GIVEN="a cow", WHEN="prodded with a stick",
THEN="moo"
>
> and turn it into this code:
>    describe Cow do
>      before(:each) do
>        @cow = Cow.new
>      end
>      it ''should say "moo" when sent
prod_with_stick'' do
>        @cow.prod_with_stick.should == "moo"
>      end
>    end
>
> It doesn''t apply rigidly to every situation, but 90% of the time,
if
> I keep chanting GIVEN WHEN THEN I write clean, focussed specs.  The
> rest is mainly vocabulary (although sometimes it can be hard to
> phrase something clearly).
I''ve been in that habit too. In general, I want the GIVEN expressed in
the String passed to describe and/or before(:each). The WHEN and THEN
should be in the example. As Ashley suggests, this isn''t 100% of the
time, but I find that the more I stick to this the easier it is to
grok everything when looking back.

Also, I try to stick to one WHEN and one THEN per example. This means
that if there are mocks involved, my examples generally look like
this:

it "should foo when bar" do
  collaborator.should_receive(:baz)
  thing.bar
end

OR

it "should foo when bar" do
  thing.bar
  thing.baz.should == something
end

BUT NEVER

it "should foo when bar" do
  collaborator.should_receive(:baz)
  thing.bar
  thing.fu.should == something
end

FWIW.

Cheers,
David


>
> Ashley
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

I think this is a nugget of experience about which it''s worth  
shouting. I''ve read lots of articles about the theory behind BDD and  
TDD, but I need(ed) help learning how to phrase and write specs. That  
is, what to spec and how to write it; what is good style, and what is  
not so good. I''d love to come up with a guide like "The Elements
of
Style" by Strunk, White, et. al, which I used in college to really  
learn how to write.

Perhaps we need to bundle "The Elements of RSpec Style" with the  
documentation on the website. I''m happy to collect and edit
suggestions.

What do you think?

-Anthony

On Jul 11, 2007, at 11:06 AM, Ashley Moran wrote:
>
> On 11 Jul 2007, at 15:00, Pedro Del Gallego wrote:
>
>>  Thats my biggest problem with rspec, (I''m a non english
speaker
>> working in a German/English environment)  It would be great a  
>> guide or
>> a tips list to make our specs more  readebles, Something like 10
>> English tips to improve your specs readability ;)
>
>
> Don''t think I can come up with 10 off the top of my head but I
always
> told Pawel to follow the rule "phrase descriptions as GIVEN WHEN
> THEN".  There''s plenty of better examples on this list and
elsewhere,
> but basically if I have an idea like this:
>
>    A cow prodded with a stick should moo
>
> I think:
>    GIVEN="a cow", WHEN="prodded with a stick",
THEN="moo"
>
> and turn it into this code:
>    describe Cow do
>      before(:each) do
>        @cow = Cow.new
>      end
>      it ''should say "moo" when sent
prod_with_stick'' do
>        @cow.prod_with_stick.should == "moo"
>      end
>    end
>
> It doesn''t apply rigidly to every situation, but 90% of the time,
if
> I keep chanting GIVEN WHEN THEN I write clean, focussed specs.  The
> rest is mainly vocabulary (although sometimes it can be hard to
> phrase something clearly).
>
> Ashley
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On 11 Jul 2007, at 17:12, Anthony Carlos wrote:
> Perhaps we need to bundle "The Elements of RSpec Style" with the
> documentation on the website. I''m happy to collect and edit  
> suggestions.
I would like to enthusiastically (albeit fundamentally unhelpfully)  
voice my support for this idea. The main win of RSpec over Test::Unit  
is the framework of linguistic constraints it provides to help guide  
people down the right path, but the main weakness is that it still  
doesn''t go far enough -- most conversations I have with people about  
BDD are concerned with the continuing struggle to work out what the  
"right way" to write specs is. Toy examples (cf Stack, Account) are  
unhelpful in this regard because they demonstrate the common-sense  
mechanics of RSpec without really delivering any accumulated wisdom  
about how real specs should look and behave, and that''s the hard part  
to grasp when you''re trying to learn this stuff.

I realise there''s a well-intentioned progressive reticence to preach  
a dogmatic gospel about how specs should be named, designed and  
constructed, but as with Rails I believe that people derive genuine  
comfort and encouragement from being told The One Correct Way when  
they''re starting out, and once they become competent enough to have  
dissenting opinions of their own they rarely seem to have a problem  
with enacting them. There are lots of gems of pragmatic wisdom dotted  
throughout the rspec-users archives -- yeah, David''s "one
WHEN/THEN
per example" is a great one -- and I think it''d be tremendously  
useful to collect and promote these as Truth even if no expert quite  
believes that they are.

Cheers,
-Tom

On 11 Jul 2007, at 17:12, Anthony Carlos wrote:
> What do you think?

I think there''s a lot of merit in that idea.  I''ve come across
loads
of situations where it was not obvious how to write the specs or code  
so that the code or specs (respectively) are clear and useful.  I''m  
sure they could be distilled to a set of template situations - I''d be  
happy to submit examples.

When people ask what developing with tests is like I tend to say that  
the difference between using RSpec and writing specs is like the  
difference between learning how a paintbrush works and learning how  
to paint a picture.  RSpec''s easy enough to pick up, but I wish I  
could point people at a more theoretical how-to that helps with the  
difficult "how do I spec this?" problems.

Ashley

If you guys don''t mind, I''m going to create a sample web page
with
this concept on it, stealing from Ashley and David''s writings. If  
people like it, perhaps we can get it included in the documentation.

On Jul 11, 2007, at 12:35 PM, Ashley Moran wrote:
>
> On 11 Jul 2007, at 17:12, Anthony Carlos wrote:
>
>> What do you think?
>
>
> I think there''s a lot of merit in that idea.  I''ve come
across loads
> of situations where it was not obvious how to write the specs or code
> so that the code or specs (respectively) are clear and useful. 
I''m
> sure they could be distilled to a set of template situations - I''d
be
> happy to submit examples.
>
> When people ask what developing with tests is like I tend to say that
> the difference between using RSpec and writing specs is like the
> difference between learning how a paintbrush works and learning how
> to paint a picture.  RSpec''s easy enough to pick up, but I wish I
> could point people at a more theoretical how-to that helps with the
> difficult "how do I spec this?" problems.
>
> Ashley
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On 7/12/07, Anthony Carlos <anthony at digitalphenom.com>
wrote:
> If you guys don''t mind, I''m going to create a sample web
page with
> this concept on it, stealing from Ashley and David''s writings. If
> people like it, perhaps we can get it included in the documentation.
>
Go ahead, that would be great!

Aslak
> On Jul 11, 2007, at 12:35 PM, Ashley Moran wrote:
>
> >
> > On 11 Jul 2007, at 17:12, Anthony Carlos wrote:
> >
> >> What do you think?
> >
> >
> > I think there''s a lot of merit in that idea.  I''ve
come across loads
> > of situations where it was not obvious how to write the specs or code
> > so that the code or specs (respectively) are clear and useful. 
I''m
> > sure they could be distilled to a set of template situations -
I''d be
> > happy to submit examples.
> >
> > When people ask what developing with tests is like I tend to say that
> > the difference between using RSpec and writing specs is like the
> > difference between learning how a paintbrush works and learning how
> > to paint a picture.  RSpec''s easy enough to pick up, but I
wish I
> > could point people at a more theoretical how-to that helps with the
> > difficult "how do I spec this?" problems.
> >
> > Ashley
> >
> >
> >
> > _______________________________________________
> > 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
>

On 12 Jul 2007, at 17:20, Anthony Carlos wrote:
> If you guys don''t mind, I''m going to create a sample web
page with
> this concept on it, stealing from Ashley and David''s writings. If
> people like it, perhaps we can get it included in the documentation.
Do you have a wiki you could use?  If not I could open a public page  
on my company''s wiki and you could edit it there - might be easier to  
do collaborative stuff that way.

Ashley

On 7/13/07, Ashley Moran <work at ashleymoran.me.uk>
wrote:
>
> On 12 Jul 2007, at 17:20, Anthony Carlos wrote:
>
> > If you guys don''t mind, I''m going to create a sample
web page with
> > this concept on it, stealing from Ashley and David''s
writings. If
> > people like it, perhaps we can get it included in the documentation.
>
> Do you have a wiki you could use?  If not I could open a public page
> on my company''s wiki and you could edit it there - might be easier
to
> do collaborative stuff that way.
We don''t right now, nor do we have resources to set one up, so if you
can set something up that would be awesome.

Thanks Ashley,
David
>
> Ashley
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 13 Jul 2007, at 13:07, David Chelimsky wrote:
> We don''t right now, nor do we have resources to set one up, so if
you
> can set something up that would be awesome.
Ok I cobbled something together on our company wiki (which runs on  
XWiki).  I''ve created an RSpecCollab space - a space is just a group  
of pages with common permissions - that is publicly viewable but only  
editable by registered users.  It''s a bit quirky but the key stuff  
seems to work.  Please let me know if I inadvertently gave the whole  
world access to our corporate secrets :)

URL:  http://www.codeweavers.net/wiki/bin/view/RSpecCollab/WebHome

I''ve made a few accounts which I will send by email in a sec.  If  
anyone else wants an account just ask and I will set one up.

Ashley

Ashley:

Thanks for the wiki page. I''ve logged-in and posted a brief statement  
about our intentions. I''m playing the role of editor here, since,
I''m
not the best at writing examples, and I''m still feeling around for  
boundaries. I don''t want to steal someone''s writings without
their
consent, but I don''t want to sprinkle people''s names for each
concept. Perhaps a thanks to each contributor in one section at the  
end will suffice?

Thanks,

-Anthony

On Jul 13, 2007, at 9:53 AM, Ashley Moran wrote:
>
> On 13 Jul 2007, at 13:07, David Chelimsky wrote:
>
>> We don''t right now, nor do we have resources to set one up, so
if you
>> can set something up that would be awesome.
>
> Ok I cobbled something together on our company wiki (which runs on
> XWiki).  I''ve created an RSpecCollab space - a space is just a
group
> of pages with common permissions - that is publicly viewable but only
> editable by registered users.  It''s a bit quirky but the key stuff
> seems to work.  Please let me know if I inadvertently gave the whole
> world access to our corporate secrets :)
>
> URL:  http://www.codeweavers.net/wiki/bin/view/RSpecCollab/WebHome
>
> I''ve made a few accounts which I will send by email in a sec.  If
> anyone else wants an account just ask and I will set one up.
>
> Ashley
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On 13 Jul 2007, at 16:58, Anthony Carlos wrote:
> Thanks for the wiki page. I''ve logged-in and posted a brief
statement
> about our intentions. I''m playing the role of editor here, since,
I''m
> not the best at writing examples, and I''m still feeling around for
> boundaries. I don''t want to steal someone''s writings
without their
> consent, but I don''t want to sprinkle people''s names for
each
> concept. Perhaps a thanks to each contributor in one section at the
> end will suffice?
I''m not too worried about my name being attached to a code sample  
that involves prodding cows with sticks :)

One thing you might want to try is splitting each example up into its  
own page.  You can make a list like this

1.1 Examples
* [GivenWhenThen]
* [SomethingElse]
* ...

then it creates links to pages that are created when  you save some  
content

(Headings are made with 1, 1.1, 1.1.1 etc)

You''ve used some square brackets to put comments in - they need a \  
in front of them to prevent them being treated as links

I might write a couple of examples based on on shared specs /  
decomposing classes problems that have come up at work.  If I get  
change I''ll write them up soon so they can be reviewed

Ashley

Thanks for the primer on the wiki. I don''t use them very often, but  
I''ll pick up the formatting stuff soon enough. I will try to set-up  
additional pages later today.

Thanks,

-Anthony

On Jul 13, 2007, at 12:13 PM, Ashley Moran wrote:
>
> On 13 Jul 2007, at 16:58, Anthony Carlos wrote:
>
>> Thanks for the wiki page. I''ve logged-in and posted a brief
statement
>> about our intentions. I''m playing the role of editor here,
since, I''m
>> not the best at writing examples, and I''m still feeling around
for
>> boundaries. I don''t want to steal someone''s writings
without their
>> consent, but I don''t want to sprinkle people''s names
for each
>> concept. Perhaps a thanks to each contributor in one section at the
>> end will suffice?
>
> I''m not too worried about my name being attached to a code sample
> that involves prodding cows with sticks :)
>
> One thing you might want to try is splitting each example up into its
> own page.  You can make a list like this
>
> 1.1 Examples
> * [GivenWhenThen]
> * [SomethingElse]
> * ...
>
> then it creates links to pages that are created when  you save some
> content
>
> (Headings are made with 1, 1.1, 1.1.1 etc)
>
> You''ve used some square brackets to put comments in - they need a
\
> in front of them to prevent them being treated as links
>
> I might write a couple of examples based on on shared specs /
> decomposing classes problems that have come up at work.  If I get
> change I''ll write them up soon so they can be reviewed
>
> Ashley
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users