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