It seems to me that the RSpec bundle''s ''it'' snippet
is in need of some
love. By default, a newly inserted spec passes. This seems odd as it
is misleading. It also makes it harder find what specs still need to
be completed if you return to an RSpec module after a break.
I propose that the ''it'' snippet is changed to the following:
it "${0:should ${1:description}}" ${3:do
${2:pending("Needs to be written")}
end}
This tweak simply adds a ''pending'' statement as the body of a
newly
created spec. When run, the tester will be alerted to an unfinished
test.
Thoughts?
Thanks!
Matt Darby, M.S.
IT Manager / Lead Web Developer
Dynamix Engineering Ltd.
1108 City Park Ave.
Columbus, OH 43206
Cell: (614) 403-5289
www.dynamix-ltd.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20080127/6907e92e/attachment.html
On Jan 26, 2008 10:50 PM, Matt Darby <matt at matt-darby.com> wrote:> It seems to me that the RSpec bundle''s ''it'' snippet is in need of some love. > By default, a newly inserted spec passes.Not if you fill it out...and the BDD way is to write one example at a time, not a complete spec beforehand.> This seems odd as it is > misleading. It also makes it harder find what specs still need to be > completed if you return to an RSpec module after a break. > > I propose that the ''it'' snippet is changed to the following: > > > it "${0:should ${1:description}}" ${3:do > ${2:pending("Needs to be written")} > end} > > This tweak simply adds a ''pending'' statement as the body of a newly created > spec. When run, the tester will be alerted to an unfinished test. > > Thoughts?That''s the wonderful thing about TextMate being so flexible, and RSpec being open source. You''re free to change it on your own machine. However I''d say that there''s no chance this change gets applied to RSpec trunk, nor should it. Pat
Hi Matt, one way of doing this is to leave the block out and just write: it "should bla bla" No ''do'', no ''end''. The example will be pending this way. Fran?ois Matt Darby schrieb:> It seems to me that the RSpec bundle''s ''it'' snippet is in need of some > love. By default, a newly inserted spec passes. This seems odd as it is > misleading. It also makes it harder find what specs still need to be > completed if you return to an RSpec module after a break. > > I propose that the ''it'' snippet is changed to the following: > > it "${0:should ${1:description}}" ${3:do > ${2:pending("Needs to be written")} > end} > > This tweak simply adds a ''pending'' statement as the body of a newly > created spec. When run, the tester will be alerted to an unfinished test. > > Thoughts? > > Thanks! > ** > *Matt Darby, M.S.* > IT Manager / Lead Web Developer > > Dynamix Engineering Ltd. > 1108 City Park Ave. > Columbus, OH 43206 > Cell: (614) 403-5289 > www.dynamix-ltd.com <http://www.dynamix-ltd.com> > > > ------------------------------------------------------------------------ > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Ah, I was unaware of this. Thanks for the pointer. On Jan 27, 2008, at 2:42 AM, Francois Wurmus wrote:> Hi Matt, > > one way of doing this is to leave the block out and just write: > it "should bla bla" > > No ''do'', no ''end''. The example will be pending this way. > > > Fran?ois
Along these lines, I also think that a empty spec should be failing or at least pending. On Jan 27, 2008, at 6:50 AM, Matt Darby wrote:> Ah, I was unaware of this. Thanks for the pointer. > > On Jan 27, 2008, at 2:42 AM, Francois Wurmus wrote: > >> Hi Matt, >> >> one way of doing this is to leave the block out and just write: >> it "should bla bla" >> >> No ''do'', no ''end''. The example will be pending this way. >> >> >> Fran?ois > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-usersJames Deville http://devillecompanies.org james.deville at gmail.com rspec r3172 rspec_on_rails r3172 rails r8331
On Jan 28, 2008 5:42 PM, James Deville <james.deville at gmail.com> wrote:> Along these lines, I also think that a empty spec should be failing or > at least pending.+1
> Not if you fill it out...and the BDD way is to write one example at a > time, not a complete spec beforehand.I''ve done it this way too (being lazy), but is it really good thing? Often I get more insight on how an interface should look like, if I think even superficially what kinds of services an object should offer. Thus I _think_ that writing a TODO-list in spec form (marking all as pending) and starting to pick up those that you want to do. Is this really considered non-BDDish by the authoritatives? If I remember correctly, Dave Astels wrote something along these lines in his book Test Driven Development (reminding that BDD is TDD done right): create a TODO list of small tasks to do, related to roles of the object, and pick something start writing tests. IMO, if you don''t think of the features at all and just start to spec completely some single functionality, you risk rewriting that test many times when you add new tests for other methods on the same object, no? -- "One day, when he was naughty, Mr Bunnsy looked over the hedge into Farmer Fred''s field and it was full of fresh green lettuces. Mr Bunnsy, however, was not full of lettuces. This did not seem fair." -- Terry Pratchett, Mr. Bunnsy Has An Adventure
On Jan 29, 2008 5:43 AM, Edvard Majakari <edvard at majakari.net> wrote:> > Not if you fill it out...and the BDD way is to write one example at a > > time, not a complete spec beforehand. > > I''ve done it this way too (being lazy), but is it really good thing? > Often I get more insight on how an interface should look like, > if I think even superficially what kinds of services an object should > offer. Thus I _think_ that writing a TODO-list in spec form > (marking all as pending) and starting to pick up those that you want > to do. Is this really considered non-BDDish by the authoritatives?When I think of extra tests that I need to write, I jot them down on a card. When I work on code, I work on one thing at a time. There are no rules though, so if writing out a bunch of specs before you do anything works for you, cool.> IMO, if you don''t think of the features at all and just start to spec > completely some single functionality, you risk rewriting that test > many times > when you add new tests for other methods on the same object, no?That has not been my experience. If you have to rewrite the same test over and over, it''s probably testing too much. Pat
Warning - bit of a ramble below! On 29/01/2008, Edvard Majakari <edvard at majakari.net> wrote:> > > Not if you fill it out...and the BDD way is to write one example at a > > time, not a complete spec beforehand. > > I''ve done it this way too (being lazy), but is it really good thing? > Often I get more insight on how an interface should look like, > if I think even superficially what kinds of services an object should > offer. Thus I _think_ that writing a TODO-list in spec form > (marking all as pending) and starting to pick up those that you want > to do. Is this really considered non-BDDish by the authoritatives? > > If I remember correctly, Dave Astels wrote something along these lines > in his book Test Driven Development > (reminding that BDD is TDD done right): create a TODO list of small > tasks to do, related to roles of the object, and pick something > start writing tests.You make some good observations. The advice to "pick something and start writing tests" was one of the alarm bells early on that told me TDD was about more than testing. I write software to solve a problem - especially commercial software - and there is usually a stakeholder involved who wants to see tangible progress. With respect, BDD is more than TDD-done-right. "Full-scale" BDD (starting at the outside with stories and scenarios and working inwards to the code) grew out of trying to identify "the next most important thing" from the stakeholder''s perspective, rather than whatever looked most interesting to me as a programmer. If you only have the close-up view of TDD - or example-level BDD (which unfortunately is what most people consider BDD to be) - it''s difficult to see what the most valuable behaviour would be, and therefore the next most important thing to implement, so you end up choosing "somewhere interesting" (i.e. somewhere arbitrary in business terms). Without business-level acceptance criteria in the form of scenarios you don''t know what "done" looks like, so it''s very tempting to capture a whole bunch of things that occur to you in case one of them is the way forward. That''s when you find yourself writing a bunch of "todo" or pending examples. If you start with a narrow, end-to-end piece of functionality and drill into it from the outside, right through until you have it working, you will find that at each layer of abstraction you will have a pretty focused subset of behaviour to implement to get the job done. IMO, if you don''t think of the features at all and just start to spec> completely some single functionality, you risk rewriting that test > many times > when you add new tests for other methods on the same object, no?You certainly risk revisiting something many times - often assumptions you made in speccing out the object without any outside-in forces to identify its actual value. If I''m honest, I find myself doing this more often than I would like, especially when I''m reworking legacy code (which is a lot of my time recently). I usually take it as an indication that I haven''t broadened my scope enough - I''m not "outside" enough to have a reasonable perspective. I stop, take a couple of steps back (usually reverting all my recent changes!) and reassess exactly who is the client of the code I''ve been tinkering with. I can relate to your point about writing a few examples to help you understand how an interface might work. Massaging code like that is a great way to explore an API. The important thing is to recognise it as just that - an exploratory exercise. Then you throw away any code you created in the process and start over, outside-in, armed with the knowledge that came out of the spike. Perhaps I ought to write this up - it''s a theme that comes up quite often. Thanks for listening, Dan --> "One day, when he was naughty, Mr Bunnsy looked over the hedge into > Farmer Fred''s field and it was full of fresh green lettuces. Mr > Bunnsy, however, was not full of lettuces. This did not seem fair." > -- Terry Pratchett, Mr. Bunnsy Has An Adventure > _______________________________________________ > 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/20080129/473b39f1/attachment-0001.html