rspec users - Jun 2007 - When to use BDD/TDD w/ external libraries

Test First Development is great...But should you use it when you are  
adding classes/methods on to external library that doesn''t have an  
extensive test suite?  I noticed that the rspec plugin for autotest  
has no specs.

David Chemlinsky said something to the list a while back that has  
been stewing in my subconscious - that you develop software  
differently using Test First Development/BDD.  I noticed that it  
would be very hard to add a spec library to autotest (I once  
performed some code coverage on it and I believe it was at something  
like 30 or 40 percent.).  So if one wanted to develop something like  
the rspec plugin to autotest, would it be wise to develop it test first?

I''m not sure if anyone else has had this difficulty, or if I''m
being
clear.  Let me know if I should clarify with some examples.

Best,

Scott

On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
> Test First Development is great...But should you use it when you are
> adding classes/methods on to external library that doesn''t have an
> extensive test suite?  I noticed that the rspec plugin for autotest
> has no specs.
>
> David Chemlinsky said something to the list a while back that has
> been stewing in my subconscious - that you develop software
> differently using Test First Development/BDD.  I noticed that it
David (Chelimsky is his last name) and Ryan Davis paired on the RSpec
plugin for Autotest at Railsconf, and I suspect that "they didn''t
have
time" to write specs for it ;-)

Look at the number of bugs that have been reported (and fixed) against
RSpec''s Autotest plugin in the previous weeks.

Maybe there is a relationship between the number of bugs and the lack
of specs? ;-)
> would be very hard to add a spec library to autotest (I once
> performed some code coverage on it and I believe it was at something
> like 30 or 40 percent.).  So if one wanted to develop something like
> the rspec plugin to autotest, would it be wise to develop it test first?
>
Any code that doesn''t have automated tests works by accident as far as
I''m concerned.
It makes no difference whether the code is using a third party library
or code whether it''s part of your own code.

However, some third party libraries (like J2EE) makes it so hard to
test any code using it that you essentially have to choose between the
third party or the ability to test. Sometimes having both is too much
work.

Aslak
> I''m not sure if anyone else has had this difficulty, or if
I''m being
> clear.  Let me know if I should clarify with some examples.
>
> Best,
>
> Scott
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

> Test First Development is great...But should you use it when you are
> adding classes/methods on to external library that doesn''t have an
> extensive test suite?  I noticed that the rspec plugin for autotest
> has no specs.

Hi,

with external libraries like rails plugins, I find RSpec great to
''secure''
the expectations that my application has over these third parties.
I don''t ''secure'' everything, only the things which
seem critical in the
context of this application.

I find this very useful before migrating a plugin to its new version, or
when replacing a plugin by another.
I also use it to reproduce bugs in those plugins.

my 0.02?!

ps: RSpec is a kind of a dream to me - the isolation provided by default is
bringing a lot of benefits to my testing process ! Thanks.

Best,

Thibaut
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070608/d47d837e/attachment.html

On 6/8/07, aslak hellesoy <aslak.hellesoy at gmail.com>
wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >
> > Test First Development is great...But should you use it when you are
> > adding classes/methods on to external library that doesn''t
have an
> > extensive test suite?  I noticed that the rspec plugin for autotest
> > has no specs.
> >
> > David Chemlinsky said something to the list a while back that has
> > been stewing in my subconscious - that you develop software
> > differently using Test First Development/BDD.  I noticed that it
>
> David (Chelimsky is his last name) and Ryan Davis paired on the RSpec
> plugin for Autotest at Railsconf, and I suspect that "they
didn''t have
> time" to write specs for it ;-)
>
> Look at the number of bugs that have been reported (and fixed) against
> RSpec''s Autotest plugin in the previous weeks.
>
> Maybe there is a relationship between the number of bugs and the lack
> of specs? ;-)
Definitely.
>
> > would be very hard to add a spec library to autotest (I once
> > performed some code coverage on it and I believe it was at something
> > like 30 or 40 percent.).  So if one wanted to develop something like
> > the rspec plugin to autotest, would it be wise to develop it test
first?
Absolutely. TDD allows for the process that Ryan and I went through
but I skipped an important step because I was excited to get it out
the door. You''re allowed to hack stuff together to figure out how it
works. But you''re then supposed to throw all of that code out and
start over, test first. I failed to take this step :(

That said, I think that most of the bugs that have been reported
wouldn''t have been tested against anyhow - they''ve mostly been
due to
conflicts between varying versions of spec.opts and file loading
issues that I never saw happen and therefore wouldn''t have likely
considered to describe.

This is part of the nature of TDD. TDD didn''t evolve in one or
two-man, all-developer shops. It evolved on teams that included
testers. The goal was never for the tests to serve as tests as far as
the customer was concerned. It was about design. It was about
documentation. It was about making the job of the tester (the official
tester w/ the title and all) easier by reducing the number of bugs
they had to deal with. This meant that they could focus more on the
really important stuff instead of getting hung up on the trivial stuff
that *should* have been caught during development. This helped to
reduce the thrashing that often occurred once you reached the testing
phase.

That''s part of why BDD came to be - to help put the focus back in the
right places: developers develop, testers test.

In the end, even the most disciplined TDD''er is only going to write
examples for the things he/she thinks of. You still should have a
tester on your team. The person who lives and breathes breaking code,
rather than developing code. We don''t have a person like that on the
RSpec team. Well, actually, we DO have that. It''s all of you! Which
means, really, we shouldn''t be making major releases without release
candidates. I think RC is open source''s informal means of exploratory
testing.
> Any code that doesn''t have automated tests works by accident as
far as
> I''m concerned.
> It makes no difference whether the code is using a third party library
> or code whether it''s part of your own code.
>
> However, some third party libraries (like J2EE) makes it so hard to
> test any code using it that you essentially have to choose between the
> third party or the ability to test. Sometimes having both is too much
> work.
In terms of rspec and autotest, I think we''re somewhere in the middle
here. Scott points out 30-40% coverage on autotest. There''s a school
of thought in TDD that says "test your own code," implying that you
don''t test 3rd party libraries. You test that your code interacts w/
the 3rd party code per the published API, but you either trust that
the 3rd party code works or you either accept the possibility of bugs
because the benefits are worth it or you don''t use it.

For me, autotest has been great. There have been some integration
problems w/ rspec but while they''ve been annoying they haven''t
instilled fear in me that I''m getting the wrong feedback. So I put up
with it.

But we could certainly get some tests around the existing integration
points: The test-to-file mappings, the command that gets generated,
etc. Patches welcome!

Cheers,
David
>
> Aslak
>
> > I''m not sure if anyone else has had this difficulty, or if
I''m being
> > clear.  Let me know if I should clarify with some examples.
> >
> > Best,
> >
> > Scott
> >
> > _______________________________________________
> > 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
>

most plugins come with their own rails tests

i''ve converted one by hand to rspec (restful_authentication) because
- its functionality is integral to my app
- its really a generator so the code ends up in my app
- there''s a good chance i''ll be making custom changes to it as
my app
develops

perhaps a tool that automatically converts rails tests to rspecs  
would be useful?
obviously thats not TDD but it would give you the code coverage
and provide a starting point if you make custom changes to the plugin


On Jun 8, 2007, at 9:48 AM, David Chelimsky wrote:
> On 6/8/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>
>>> Test First Development is great...But should you use it when you
are
>>> adding classes/methods on to external library that doesn''t
have an
>>> extensive test suite?  I noticed that the rspec plugin for autotest
>>> has no specs.
>>>
>>> David Chemlinsky said something to the list a while back that has
>>> been stewing in my subconscious - that you develop software
>>> differently using Test First Development/BDD.  I noticed that it
>>
>> David (Chelimsky is his last name) and Ryan Davis paired on the RSpec
>> plugin for Autotest at Railsconf, and I suspect that "they
didn''t
>> have
>> time" to write specs for it ;-)
>>
>> Look at the number of bugs that have been reported (and fixed)  
>> against
>> RSpec''s Autotest plugin in the previous weeks.
>>
>> Maybe there is a relationship between the number of bugs and the lack
>> of specs? ;-)
>
> Definitely.
>
>>
>>> would be very hard to add a spec library to autotest (I once
>>> performed some code coverage on it and I believe it was at
something
>>> like 30 or 40 percent.).  So if one wanted to develop something
like
>>> the rspec plugin to autotest, would it be wise to develop it test  
>>> first?
>
> Absolutely. TDD allows for the process that Ryan and I went through
> but I skipped an important step because I was excited to get it out
> the door. You''re allowed to hack stuff together to figure out how
it
> works. But you''re then supposed to throw all of that code out and
> start over, test first. I failed to take this step :(
>
> That said, I think that most of the bugs that have been reported
> wouldn''t have been tested against anyhow - they''ve mostly
been due to
> conflicts between varying versions of spec.opts and file loading
> issues that I never saw happen and therefore wouldn''t have likely
> considered to describe.
>
> This is part of the nature of TDD. TDD didn''t evolve in one or
> two-man, all-developer shops. It evolved on teams that included
> testers. The goal was never for the tests to serve as tests as far as
> the customer was concerned. It was about design. It was about
> documentation. It was about making the job of the tester (the official
> tester w/ the title and all) easier by reducing the number of bugs
> they had to deal with. This meant that they could focus more on the
> really important stuff instead of getting hung up on the trivial stuff
> that *should* have been caught during development. This helped to
> reduce the thrashing that often occurred once you reached the testing
> phase.
>
> That''s part of why BDD came to be - to help put the focus back in
the
> right places: developers develop, testers test.
>
> In the end, even the most disciplined TDD''er is only going to
write
> examples for the things he/she thinks of. You still should have a
> tester on your team. The person who lives and breathes breaking code,
> rather than developing code. We don''t have a person like that on
the
> RSpec team. Well, actually, we DO have that. It''s all of you!
Which
> means, really, we shouldn''t be making major releases without
release
> candidates. I think RC is open source''s informal means of
exploratory
> testing.
>
>> Any code that doesn''t have automated tests works by accident
as
>> far as
>> I''m concerned.
>> It makes no difference whether the code is using a third party  
>> library
>> or code whether it''s part of your own code.
>>
>> However, some third party libraries (like J2EE) makes it so hard to
>> test any code using it that you essentially have to choose between  
>> the
>> third party or the ability to test. Sometimes having both is too much
>> work.
>
> In terms of rspec and autotest, I think we''re somewhere in the
middle
> here. Scott points out 30-40% coverage on autotest. There''s a
school
> of thought in TDD that says "test your own code," implying that
you
> don''t test 3rd party libraries. You test that your code interacts
w/
> the 3rd party code per the published API, but you either trust that
> the 3rd party code works or you either accept the possibility of bugs
> because the benefits are worth it or you don''t use it.
>
> For me, autotest has been great. There have been some integration
> problems w/ rspec but while they''ve been annoying they
haven''t
> instilled fear in me that I''m getting the wrong feedback. So I put
up
> with it.
>
> But we could certainly get some tests around the existing integration
> points: The test-to-file mappings, the command that gets generated,
> etc. Patches welcome!
>
> Cheers,
> David
>
>>
>> Aslak
>>
>>> I''m not sure if anyone else has had this difficulty, or if
I''m being
>>> clear.  Let me know if I should clarify with some examples.
>>>
>>> Best,
>>>
>>> Scott
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On 6/8/07, Jonathan Linowes <jonathan at parkerhill.com>
wrote:
> most plugins come with their own rails tests
>
> i''ve converted one by hand to rspec (restful_authentication)
because
> - its functionality is integral to my app
> - its really a generator so the code ends up in my app
> - there''s a good chance i''ll be making custom changes to
it as my app
> develops
>
> perhaps a tool that automatically converts rails tests to rspecs
> would be useful?
We had one of those a while back. It was pretty good, but not perfect.
It''s very complex to get right and cover all the possibilities and
it''s something that we will likely not build as part of rspec. That
said, if somebody else wanted to create such a thing, I''m sure
you''d
make a lot of people happy.
> obviously thats not TDD but it would give you the code coverage
> and provide a starting point if you make custom changes to the plugin
>
>
> On Jun 8, 2007, at 9:48 AM, David Chelimsky wrote:
>
> > On 6/8/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> >> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
> >>>
> >>> Test First Development is great...But should you use it when
you are
> >>> adding classes/methods on to external library that
doesn''t have an
> >>> extensive test suite?  I noticed that the rspec plugin for
autotest
> >>> has no specs.
> >>>
> >>> David Chemlinsky said something to the list a while back that
has
> >>> been stewing in my subconscious - that you develop software
> >>> differently using Test First Development/BDD.  I noticed that
it
> >>
> >> David (Chelimsky is his last name) and Ryan Davis paired on the
RSpec
> >> plugin for Autotest at Railsconf, and I suspect that "they
didn''t
> >> have
> >> time" to write specs for it ;-)
> >>
> >> Look at the number of bugs that have been reported (and fixed)
> >> against
> >> RSpec''s Autotest plugin in the previous weeks.
> >>
> >> Maybe there is a relationship between the number of bugs and the
lack
> >> of specs? ;-)
> >
> > Definitely.
> >
> >>
> >>> would be very hard to add a spec library to autotest (I once
> >>> performed some code coverage on it and I believe it was at
something
> >>> like 30 or 40 percent.).  So if one wanted to develop
something like
> >>> the rspec plugin to autotest, would it be wise to develop it
test
> >>> first?
> >
> > Absolutely. TDD allows for the process that Ryan and I went through
> > but I skipped an important step because I was excited to get it out
> > the door. You''re allowed to hack stuff together to figure out
how it
> > works. But you''re then supposed to throw all of that code out
and
> > start over, test first. I failed to take this step :(
> >
> > That said, I think that most of the bugs that have been reported
> > wouldn''t have been tested against anyhow - they''ve
mostly been due to
> > conflicts between varying versions of spec.opts and file loading
> > issues that I never saw happen and therefore wouldn''t have
likely
> > considered to describe.
> >
> > This is part of the nature of TDD. TDD didn''t evolve in one
or
> > two-man, all-developer shops. It evolved on teams that included
> > testers. The goal was never for the tests to serve as tests as far as
> > the customer was concerned. It was about design. It was about
> > documentation. It was about making the job of the tester (the official
> > tester w/ the title and all) easier by reducing the number of bugs
> > they had to deal with. This meant that they could focus more on the
> > really important stuff instead of getting hung up on the trivial stuff
> > that *should* have been caught during development. This helped to
> > reduce the thrashing that often occurred once you reached the testing
> > phase.
> >
> > That''s part of why BDD came to be - to help put the focus
back in the
> > right places: developers develop, testers test.
> >
> > In the end, even the most disciplined TDD''er is only going to
write
> > examples for the things he/she thinks of. You still should have a
> > tester on your team. The person who lives and breathes breaking code,
> > rather than developing code. We don''t have a person like that
on the
> > RSpec team. Well, actually, we DO have that. It''s all of you!
Which
> > means, really, we shouldn''t be making major releases without
release
> > candidates. I think RC is open source''s informal means of
exploratory
> > testing.
> >
> >> Any code that doesn''t have automated tests works by
accident as
> >> far as
> >> I''m concerned.
> >> It makes no difference whether the code is using a third party
> >> library
> >> or code whether it''s part of your own code.
> >>
> >> However, some third party libraries (like J2EE) makes it so hard
to
> >> test any code using it that you essentially have to choose between
> >> the
> >> third party or the ability to test. Sometimes having both is too
much
> >> work.
> >
> > In terms of rspec and autotest, I think we''re somewhere in
the middle
> > here. Scott points out 30-40% coverage on autotest. There''s a
school
> > of thought in TDD that says "test your own code," implying
that you
> > don''t test 3rd party libraries. You test that your code
interacts w/
> > the 3rd party code per the published API, but you either trust that
> > the 3rd party code works or you either accept the possibility of bugs
> > because the benefits are worth it or you don''t use it.
> >
> > For me, autotest has been great. There have been some integration
> > problems w/ rspec but while they''ve been annoying they
haven''t
> > instilled fear in me that I''m getting the wrong feedback. So
I put up
> > with it.
> >
> > But we could certainly get some tests around the existing integration
> > points: The test-to-file mappings, the command that gets generated,
> > etc. Patches welcome!
> >
> > Cheers,
> > David
> >
> >>
> >> Aslak
> >>
> >>> I''m not sure if anyone else has had this difficulty,
or if I''m being
> >>> clear.  Let me know if I should clarify with some examples.
> >>>
> >>> Best,
> >>>
> >>> Scott
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> > _______________________________________________
> > 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 Jun 8, 2007, at 1:06 PM, Jonathan Linowes wrote:
> most plugins come with their own rails tests
>
> i''ve converted one by hand to rspec (restful_authentication)
because
> - its functionality is integral to my app
> - its really a generator so the code ends up in my app
> - there''s a good chance i''ll be making custom changes to
it as my app
> develops
>
I thought about doing the same thing a while back.  You might want to  
send those specs back to Rick Olson.

Scott

> On Jun 8, 2007, at 9:48 AM, David Chelimsky wrote:
>
>> On 6/8/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>>> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>>>>
>>>> Test First Development is great...But should you use it when
you
>>>> are
>>>> adding classes/methods on to external library that
doesn''t have an
>>>> extensive test suite?  I noticed that the rspec plugin for
autotest
>>>> has no specs.
>>>>
>>>> David Chemlinsky said something to the list a while back that
has
>>>> been stewing in my subconscious - that you develop software
>>>> differently using Test First Development/BDD.  I noticed that
it
>>>
>>> David (Chelimsky is his last name) and Ryan Davis paired on the  
>>> RSpec
>>> plugin for Autotest at Railsconf, and I suspect that "they
didn''t
>>> have
>>> time" to write specs for it ;-)
>>>
>>> Look at the number of bugs that have been reported (and fixed)
>>> against
>>> RSpec''s Autotest plugin in the previous weeks.
>>>
>>> Maybe there is a relationship between the number of bugs and the  
>>> lack
>>> of specs? ;-)
>>
>> Definitely.
>>
>>>
>>>> would be very hard to add a spec library to autotest (I once
>>>> performed some code coverage on it and I believe it was at  
>>>> something
>>>> like 30 or 40 percent.).  So if one wanted to develop something
>>>> like
>>>> the rspec plugin to autotest, would it be wise to develop it
test
>>>> first?
>>
>> Absolutely. TDD allows for the process that Ryan and I went through
>> but I skipped an important step because I was excited to get it out
>> the door. You''re allowed to hack stuff together to figure out
how it
>> works. But you''re then supposed to throw all of that code out
and
>> start over, test first. I failed to take this step :(
>>
>> That said, I think that most of the bugs that have been reported
>> wouldn''t have been tested against anyhow - they''ve
mostly been due to
>> conflicts between varying versions of spec.opts and file loading
>> issues that I never saw happen and therefore wouldn''t have
likely
>> considered to describe.
>>
>> This is part of the nature of TDD. TDD didn''t evolve in one or
>> two-man, all-developer shops. It evolved on teams that included
>> testers. The goal was never for the tests to serve as tests as far as
>> the customer was concerned. It was about design. It was about
>> documentation. It was about making the job of the tester (the  
>> official
>> tester w/ the title and all) easier by reducing the number of bugs
>> they had to deal with. This meant that they could focus more on the
>> really important stuff instead of getting hung up on the trivial  
>> stuff
>> that *should* have been caught during development. This helped to
>> reduce the thrashing that often occurred once you reached the testing
>> phase.
>>
>> That''s part of why BDD came to be - to help put the focus back
in the
>> right places: developers develop, testers test.
>>
>> In the end, even the most disciplined TDD''er is only going to
write
>> examples for the things he/she thinks of. You still should have a
>> tester on your team. The person who lives and breathes breaking code,
>> rather than developing code. We don''t have a person like that
on the
>> RSpec team. Well, actually, we DO have that. It''s all of you!
Which
>> means, really, we shouldn''t be making major releases without
release
>> candidates. I think RC is open source''s informal means of
exploratory
>> testing.
>>
>>> Any code that doesn''t have automated tests works by
accident as
>>> far as
>>> I''m concerned.
>>> It makes no difference whether the code is using a third party
>>> library
>>> or code whether it''s part of your own code.
>>>
>>> However, some third party libraries (like J2EE) makes it so hard to
>>> test any code using it that you essentially have to choose between
>>> the
>>> third party or the ability to test. Sometimes having both is too  
>>> much
>>> work.
>>
>> In terms of rspec and autotest, I think we''re somewhere in the
middle
>> here. Scott points out 30-40% coverage on autotest. There''s a
school
>> of thought in TDD that says "test your own code," implying
that you
>> don''t test 3rd party libraries. You test that your code
interacts w/
>> the 3rd party code per the published API, but you either trust that
>> the 3rd party code works or you either accept the possibility of bugs
>> because the benefits are worth it or you don''t use it.
>>
>> For me, autotest has been great. There have been some integration
>> problems w/ rspec but while they''ve been annoying they
haven''t
>> instilled fear in me that I''m getting the wrong feedback. So I
put up
>> with it.
>>
>> But we could certainly get some tests around the existing integration
>> points: The test-to-file mappings, the command that gets generated,
>> etc. Patches welcome!
>>
>> Cheers,
>> David
>>
>>>
>>> Aslak
>>>
>>>> I''m not sure if anyone else has had this difficulty,
or if I''m
>>>> being
>>>> clear.  Let me know if I should clarify with some examples.
>>>>
>>>> Best,
>>>>
>>>> Scott
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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 Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
> On 6/8/07, Jonathan Linowes <jonathan at parkerhill.com> wrote:
>> most plugins come with their own rails tests
>>
>> i''ve converted one by hand to rspec (restful_authentication)
because
>> - its functionality is integral to my app
>> - its really a generator so the code ends up in my app
>> - there''s a good chance i''ll be making custom changes
to it as my app
>> develops
>>
>> perhaps a tool that automatically converts rails tests to rspecs
>> would be useful?
>
> We had one of those a while back. It was pretty good, but not perfect.
> It''s very complex to get right and cover all the possibilities and
> it''s something that we will likely not build as part of rspec.
That
> said, if somebody else wanted to create such a thing, I''m sure
you''d
> make a lot of people happy.

Wow.  That code must still be around somewhere in subversion (any  
hints as to it''s last release?)

Scott


>
>> obviously thats not TDD but it would give you the code coverage
>> and provide a starting point if you make custom changes to the plugin
>>
>>
>> On Jun 8, 2007, at 9:48 AM, David Chelimsky wrote:
>>
>>> On 6/8/07, aslak hellesoy <aslak.hellesoy at gmail.com>
wrote:
>>>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
>>>>>
>>>>> Test First Development is great...But should you use it
when
>>>>> you are
>>>>> adding classes/methods on to external library that
doesn''t have an
>>>>> extensive test suite?  I noticed that the rspec plugin for
>>>>> autotest
>>>>> has no specs.
>>>>>
>>>>> David Chemlinsky said something to the list a while back
that has
>>>>> been stewing in my subconscious - that you develop software
>>>>> differently using Test First Development/BDD.  I noticed
that it
>>>>
>>>> David (Chelimsky is his last name) and Ryan Davis paired on the
>>>> RSpec
>>>> plugin for Autotest at Railsconf, and I suspect that "they
didn''t
>>>> have
>>>> time" to write specs for it ;-)
>>>>
>>>> Look at the number of bugs that have been reported (and fixed)
>>>> against
>>>> RSpec''s Autotest plugin in the previous weeks.
>>>>
>>>> Maybe there is a relationship between the number of bugs and
the
>>>> lack
>>>> of specs? ;-)
>>>
>>> Definitely.
>>>
>>>>
>>>>> would be very hard to add a spec library to autotest (I
once
>>>>> performed some code coverage on it and I believe it was at
>>>>> something
>>>>> like 30 or 40 percent.).  So if one wanted to develop
something
>>>>> like
>>>>> the rspec plugin to autotest, would it be wise to develop
it test
>>>>> first?
>>>
>>> Absolutely. TDD allows for the process that Ryan and I went through
>>> but I skipped an important step because I was excited to get it out
>>> the door. You''re allowed to hack stuff together to figure
out how it
>>> works. But you''re then supposed to throw all of that code
out and
>>> start over, test first. I failed to take this step :(
>>>
>>> That said, I think that most of the bugs that have been reported
>>> wouldn''t have been tested against anyhow -
they''ve mostly been
>>> due to
>>> conflicts between varying versions of spec.opts and file loading
>>> issues that I never saw happen and therefore wouldn''t have
likely
>>> considered to describe.
>>>
>>> This is part of the nature of TDD. TDD didn''t evolve in
one or
>>> two-man, all-developer shops. It evolved on teams that included
>>> testers. The goal was never for the tests to serve as tests as  
>>> far as
>>> the customer was concerned. It was about design. It was about
>>> documentation. It was about making the job of the tester (the  
>>> official
>>> tester w/ the title and all) easier by reducing the number of bugs
>>> they had to deal with. This meant that they could focus more on the
>>> really important stuff instead of getting hung up on the trivial  
>>> stuff
>>> that *should* have been caught during development. This helped to
>>> reduce the thrashing that often occurred once you reached the  
>>> testing
>>> phase.
>>>
>>> That''s part of why BDD came to be - to help put the focus
back in
>>> the
>>> right places: developers develop, testers test.
>>>
>>> In the end, even the most disciplined TDD''er is only going
to write
>>> examples for the things he/she thinks of. You still should have a
>>> tester on your team. The person who lives and breathes breaking  
>>> code,
>>> rather than developing code. We don''t have a person like
that on the
>>> RSpec team. Well, actually, we DO have that. It''s all of
you! Which
>>> means, really, we shouldn''t be making major releases
without release
>>> candidates. I think RC is open source''s informal means of
>>> exploratory
>>> testing.
>>>
>>>> Any code that doesn''t have automated tests works by
accident as
>>>> far as
>>>> I''m concerned.
>>>> It makes no difference whether the code is using a third party
>>>> library
>>>> or code whether it''s part of your own code.
>>>>
>>>> However, some third party libraries (like J2EE) makes it so
hard to
>>>> test any code using it that you essentially have to choose
between
>>>> the
>>>> third party or the ability to test. Sometimes having both is
too
>>>> much
>>>> work.
>>>
>>> In terms of rspec and autotest, I think we''re somewhere in
the
>>> middle
>>> here. Scott points out 30-40% coverage on autotest.
There''s a school
>>> of thought in TDD that says "test your own code,"
implying that you
>>> don''t test 3rd party libraries. You test that your code
interacts w/
>>> the 3rd party code per the published API, but you either trust that
>>> the 3rd party code works or you either accept the possibility of  
>>> bugs
>>> because the benefits are worth it or you don''t use it.
>>>
>>> For me, autotest has been great. There have been some integration
>>> problems w/ rspec but while they''ve been annoying they
haven''t
>>> instilled fear in me that I''m getting the wrong feedback.
So I
>>> put up
>>> with it.
>>>
>>> But we could certainly get some tests around the existing  
>>> integration
>>> points: The test-to-file mappings, the command that gets generated,
>>> etc. Patches welcome!
>>>
>>> Cheers,
>>> David
>>>
>>>>
>>>> Aslak
>>>>
>>>>> I''m not sure if anyone else has had this
difficulty, or if I''m
>>>>> being
>>>>> clear.  Let me know if I should clarify with some examples.
>>>>>
>>>>> Best,
>>>>>
>>>>> Scott
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
> On Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
>
> > On 6/8/07, Jonathan Linowes <jonathan at parkerhill.com> wrote:
> >> most plugins come with their own rails tests
> >>
> >> i''ve converted one by hand to rspec
(restful_authentication) because
> >> - its functionality is integral to my app
> >> - its really a generator so the code ends up in my app
> >> - there''s a good chance i''ll be making custom
changes to it as my app
> >> develops
> >>
> >> perhaps a tool that automatically converts rails tests to rspecs
> >> would be useful?
> >
> > We had one of those a while back. It was pretty good, but not perfect.
> > It''s very complex to get right and cover all the
possibilities and
> > it''s something that we will likely not build as part of
rspec. That
> > said, if somebody else wanted to create such a thing, I''m
sure you''d
> > make a lot of people happy.
>
>
> Wow.  That code must still be around somewhere in subversion (any
> hints as to it''s last release?)
hint: svn log
>
> Scott
>
>
>
> >
> >> obviously thats not TDD but it would give you the code coverage
> >> and provide a starting point if you make custom changes to the
plugin
> >>
> >>
> >> On Jun 8, 2007, at 9:48 AM, David Chelimsky wrote:
> >>
> >>> On 6/8/07, aslak hellesoy <aslak.hellesoy at gmail.com>
wrote:
> >>>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
> >>>>>
> >>>>> Test First Development is great...But should you use
it when
> >>>>> you are
> >>>>> adding classes/methods on to external library that
doesn''t have an
> >>>>> extensive test suite?  I noticed that the rspec plugin
for
> >>>>> autotest
> >>>>> has no specs.
> >>>>>
> >>>>> David Chemlinsky said something to the list a while
back that has
> >>>>> been stewing in my subconscious - that you develop
software
> >>>>> differently using Test First Development/BDD.  I
noticed that it
> >>>>
> >>>> David (Chelimsky is his last name) and Ryan Davis paired
on the
> >>>> RSpec
> >>>> plugin for Autotest at Railsconf, and I suspect that
"they didn''t
> >>>> have
> >>>> time" to write specs for it ;-)
> >>>>
> >>>> Look at the number of bugs that have been reported (and
fixed)
> >>>> against
> >>>> RSpec''s Autotest plugin in the previous weeks.
> >>>>
> >>>> Maybe there is a relationship between the number of bugs
and the
> >>>> lack
> >>>> of specs? ;-)
> >>>
> >>> Definitely.
> >>>
> >>>>
> >>>>> would be very hard to add a spec library to autotest
(I once
> >>>>> performed some code coverage on it and I believe it
was at
> >>>>> something
> >>>>> like 30 or 40 percent.).  So if one wanted to develop
something
> >>>>> like
> >>>>> the rspec plugin to autotest, would it be wise to
develop it test
> >>>>> first?
> >>>
> >>> Absolutely. TDD allows for the process that Ryan and I went
through
> >>> but I skipped an important step because I was excited to get
it out
> >>> the door. You''re allowed to hack stuff together to
figure out how it
> >>> works. But you''re then supposed to throw all of that
code out and
> >>> start over, test first. I failed to take this step :(
> >>>
> >>> That said, I think that most of the bugs that have been
reported
> >>> wouldn''t have been tested against anyhow -
they''ve mostly been
> >>> due to
> >>> conflicts between varying versions of spec.opts and file
loading
> >>> issues that I never saw happen and therefore wouldn''t
have likely
> >>> considered to describe.
> >>>
> >>> This is part of the nature of TDD. TDD didn''t evolve
in one or
> >>> two-man, all-developer shops. It evolved on teams that
included
> >>> testers. The goal was never for the tests to serve as tests as
> >>> far as
> >>> the customer was concerned. It was about design. It was about
> >>> documentation. It was about making the job of the tester (the
> >>> official
> >>> tester w/ the title and all) easier by reducing the number of
bugs
> >>> they had to deal with. This meant that they could focus more
on the
> >>> really important stuff instead of getting hung up on the
trivial
> >>> stuff
> >>> that *should* have been caught during development. This helped
to
> >>> reduce the thrashing that often occurred once you reached the
> >>> testing
> >>> phase.
> >>>
> >>> That''s part of why BDD came to be - to help put the
focus back in
> >>> the
> >>> right places: developers develop, testers test.
> >>>
> >>> In the end, even the most disciplined TDD''er is only
going to write
> >>> examples for the things he/she thinks of. You still should
have a
> >>> tester on your team. The person who lives and breathes
breaking
> >>> code,
> >>> rather than developing code. We don''t have a person
like that on the
> >>> RSpec team. Well, actually, we DO have that. It''s all
of you! Which
> >>> means, really, we shouldn''t be making major releases
without release
> >>> candidates. I think RC is open source''s informal
means of
> >>> exploratory
> >>> testing.
> >>>
> >>>> Any code that doesn''t have automated tests works
by accident as
> >>>> far as
> >>>> I''m concerned.
> >>>> It makes no difference whether the code is using a third
party
> >>>> library
> >>>> or code whether it''s part of your own code.
> >>>>
> >>>> However, some third party libraries (like J2EE) makes it
so hard to
> >>>> test any code using it that you essentially have to choose
between
> >>>> the
> >>>> third party or the ability to test. Sometimes having both
is too
> >>>> much
> >>>> work.
> >>>
> >>> In terms of rspec and autotest, I think we''re
somewhere in the
> >>> middle
> >>> here. Scott points out 30-40% coverage on autotest.
There''s a school
> >>> of thought in TDD that says "test your own code,"
implying that you
> >>> don''t test 3rd party libraries. You test that your
code interacts w/
> >>> the 3rd party code per the published API, but you either trust
that
> >>> the 3rd party code works or you either accept the possibility
of
> >>> bugs
> >>> because the benefits are worth it or you don''t use
it.
> >>>
> >>> For me, autotest has been great. There have been some
integration
> >>> problems w/ rspec but while they''ve been annoying
they haven''t
> >>> instilled fear in me that I''m getting the wrong
feedback. So I
> >>> put up
> >>> with it.
> >>>
> >>> But we could certainly get some tests around the existing
> >>> integration
> >>> points: The test-to-file mappings, the command that gets
generated,
> >>> etc. Patches welcome!
> >>>
> >>> Cheers,
> >>> David
> >>>
> >>>>
> >>>> Aslak
> >>>>
> >>>>> I''m not sure if anyone else has had this
difficulty, or if I''m
> >>>>> being
> >>>>> clear.  Let me know if I should clarify with some
examples.
> >>>>>
> >>>>> Best,
> >>>>>
> >>>>> Scott
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>> _______________________________________________
> >>> 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
> >>
> > _______________________________________________
> > 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 6/8/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >
> > On Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
> >
> > > On 6/8/07, Jonathan Linowes <jonathan at parkerhill.com>
wrote:
> > >> most plugins come with their own rails tests
> > >>
> > >> i''ve converted one by hand to rspec
(restful_authentication) because
> > >> - its functionality is integral to my app
> > >> - its really a generator so the code ends up in my app
> > >> - there''s a good chance i''ll be making
custom changes to it as my app
> > >> develops
> > >>
> > >> perhaps a tool that automatically converts rails tests to
rspecs
> > >> would be useful?
> > >
> > > We had one of those a while back. It was pretty good, but not
perfect.
> > > It''s very complex to get right and cover all the
possibilities and
> > > it''s something that we will likely not build as part of
rspec. That
> > > said, if somebody else wanted to create such a thing,
I''m sure you''d
> > > make a lot of people happy.
> >
> >
> > Wow.  That code must still be around somewhere in subversion (any
> > hints as to it''s last release?)
>
> hint: svn log
hint 2: http://rspec.rubyforge.org/changes.html (look for test2spec)
>
> >
> > Scott
> >
> >
> >
> > >
> > >> obviously thats not TDD but it would give you the code
coverage
> > >> and provide a starting point if you make custom changes to
the plugin
> > >>
> > >>
> > >> On Jun 8, 2007, at 9:48 AM, David Chelimsky wrote:
> > >>
> > >>> On 6/8/07, aslak hellesoy <aslak.hellesoy at
gmail.com> wrote:
> > >>>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
> > >>>>>
> > >>>>> Test First Development is great...But should you
use it when
> > >>>>> you are
> > >>>>> adding classes/methods on to external library
that doesn''t have an
> > >>>>> extensive test suite?  I noticed that the rspec
plugin for
> > >>>>> autotest
> > >>>>> has no specs.
> > >>>>>
> > >>>>> David Chemlinsky said something to the list a
while back that has
> > >>>>> been stewing in my subconscious - that you
develop software
> > >>>>> differently using Test First Development/BDD.  I
noticed that it
> > >>>>
> > >>>> David (Chelimsky is his last name) and Ryan Davis
paired on the
> > >>>> RSpec
> > >>>> plugin for Autotest at Railsconf, and I suspect that
"they didn''t
> > >>>> have
> > >>>> time" to write specs for it ;-)
> > >>>>
> > >>>> Look at the number of bugs that have been reported
(and fixed)
> > >>>> against
> > >>>> RSpec''s Autotest plugin in the previous
weeks.
> > >>>>
> > >>>> Maybe there is a relationship between the number of
bugs and the
> > >>>> lack
> > >>>> of specs? ;-)
> > >>>
> > >>> Definitely.
> > >>>
> > >>>>
> > >>>>> would be very hard to add a spec library to
autotest (I once
> > >>>>> performed some code coverage on it and I believe
it was at
> > >>>>> something
> > >>>>> like 30 or 40 percent.).  So if one wanted to
develop something
> > >>>>> like
> > >>>>> the rspec plugin to autotest, would it be wise to
develop it test
> > >>>>> first?
> > >>>
> > >>> Absolutely. TDD allows for the process that Ryan and I
went through
> > >>> but I skipped an important step because I was excited to
get it out
> > >>> the door. You''re allowed to hack stuff together
to figure out how it
> > >>> works. But you''re then supposed to throw all of
that code out and
> > >>> start over, test first. I failed to take this step :(
> > >>>
> > >>> That said, I think that most of the bugs that have been
reported
> > >>> wouldn''t have been tested against anyhow -
they''ve mostly been
> > >>> due to
> > >>> conflicts between varying versions of spec.opts and file
loading
> > >>> issues that I never saw happen and therefore
wouldn''t have likely
> > >>> considered to describe.
> > >>>
> > >>> This is part of the nature of TDD. TDD didn''t
evolve in one or
> > >>> two-man, all-developer shops. It evolved on teams that
included
> > >>> testers. The goal was never for the tests to serve as
tests as
> > >>> far as
> > >>> the customer was concerned. It was about design. It was
about
> > >>> documentation. It was about making the job of the tester
(the
> > >>> official
> > >>> tester w/ the title and all) easier by reducing the
number of bugs
> > >>> they had to deal with. This meant that they could focus
more on the
> > >>> really important stuff instead of getting hung up on the
trivial
> > >>> stuff
> > >>> that *should* have been caught during development. This
helped to
> > >>> reduce the thrashing that often occurred once you reached
the
> > >>> testing
> > >>> phase.
> > >>>
> > >>> That''s part of why BDD came to be - to help put
the focus back in
> > >>> the
> > >>> right places: developers develop, testers test.
> > >>>
> > >>> In the end, even the most disciplined TDD''er is
only going to write
> > >>> examples for the things he/she thinks of. You still
should have a
> > >>> tester on your team. The person who lives and breathes
breaking
> > >>> code,
> > >>> rather than developing code. We don''t have a
person like that on the
> > >>> RSpec team. Well, actually, we DO have that.
It''s all of you! Which
> > >>> means, really, we shouldn''t be making major
releases without release
> > >>> candidates. I think RC is open source''s informal
means of
> > >>> exploratory
> > >>> testing.
> > >>>
> > >>>> Any code that doesn''t have automated tests
works by accident as
> > >>>> far as
> > >>>> I''m concerned.
> > >>>> It makes no difference whether the code is using a
third party
> > >>>> library
> > >>>> or code whether it''s part of your own code.
> > >>>>
> > >>>> However, some third party libraries (like J2EE) makes
it so hard to
> > >>>> test any code using it that you essentially have to
choose between
> > >>>> the
> > >>>> third party or the ability to test. Sometimes having
both is too
> > >>>> much
> > >>>> work.
> > >>>
> > >>> In terms of rspec and autotest, I think we''re
somewhere in the
> > >>> middle
> > >>> here. Scott points out 30-40% coverage on autotest.
There''s a school
> > >>> of thought in TDD that says "test your own
code," implying that you
> > >>> don''t test 3rd party libraries. You test that
your code interacts w/
> > >>> the 3rd party code per the published API, but you either
trust that
> > >>> the 3rd party code works or you either accept the
possibility of
> > >>> bugs
> > >>> because the benefits are worth it or you don''t
use it.
> > >>>
> > >>> For me, autotest has been great. There have been some
integration
> > >>> problems w/ rspec but while they''ve been
annoying they haven''t
> > >>> instilled fear in me that I''m getting the wrong
feedback. So I
> > >>> put up
> > >>> with it.
> > >>>
> > >>> But we could certainly get some tests around the existing
> > >>> integration
> > >>> points: The test-to-file mappings, the command that gets
generated,
> > >>> etc. Patches welcome!
> > >>>
> > >>> Cheers,
> > >>> David
> > >>>
> > >>>>
> > >>>> Aslak
> > >>>>
> > >>>>> I''m not sure if anyone else has had this
difficulty, or if I''m
> > >>>>> being
> > >>>>> clear.  Let me know if I should clarify with some
examples.
> > >>>>>
> > >>>>> Best,
> > >>>>>
> > >>>>> Scott
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> 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
> > >>>>
> > >>> _______________________________________________
> > >>> 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
> > >>
> > > _______________________________________________
> > > 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 Jun 8, 2007, at 1:23 PM, David Chelimsky wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> On Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
>>
>>> On 6/8/07, Jonathan Linowes <jonathan at parkerhill.com>
wrote:
>>>> most plugins come with their own rails tests
>>>>
>>>> i''ve converted one by hand to rspec
(restful_authentication)
>>>> because
>>>> - its functionality is integral to my app
>>>> - its really a generator so the code ends up in my app
>>>> - there''s a good chance i''ll be making custom
changes to it as
>>>> my app
>>>> develops
>>>>
>>>> perhaps a tool that automatically converts rails tests to
rspecs
>>>> would be useful?
>>>
>>> We had one of those a while back. It was pretty good, but not  
>>> perfect.
>>> It''s very complex to get right and cover all the
possibilities and
>>> it''s something that we will likely not build as part of
rspec. That
>>> said, if somebody else wanted to create such a thing, I''m
sure you''d
>>> make a lot of people happy.
>>
>>
>> Wow.  That code must still be around somewhere in subversion (any
>> hints as to it''s last release?)
>
> hint: svn log
Sorry.  I wasn''t thinking.

Scott

On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
> On Jun 8, 2007, at 1:23 PM, David Chelimsky wrote:
>
> > On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
> >>
> >> On Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
> >>
> >>> On 6/8/07, Jonathan Linowes <jonathan at parkerhill.com>
wrote:
> >>>> most plugins come with their own rails tests
> >>>>
> >>>> i''ve converted one by hand to rspec
(restful_authentication)
> >>>> because
> >>>> - its functionality is integral to my app
> >>>> - its really a generator so the code ends up in my app
> >>>> - there''s a good chance i''ll be making
custom changes to it as
> >>>> my app
> >>>> develops
> >>>>
> >>>> perhaps a tool that automatically converts rails tests to
rspecs
> >>>> would be useful?
> >>>
> >>> We had one of those a while back. It was pretty good, but not
> >>> perfect.
> >>> It''s very complex to get right and cover all the
possibilities and
> >>> it''s something that we will likely not build as part
of rspec. That
> >>> said, if somebody else wanted to create such a thing,
I''m sure you''d
> >>> make a lot of people happy.
> >>
> >>
> >> Wow.  That code must still be around somewhere in subversion (any
> >> hints as to it''s last release?)
> >
> > hint: svn log
>
> Sorry.  I wasn''t thinking.
Please - no apology necessary. Just trying to teach a man to fish ....

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

Well, actually my problem wasn''t thinking of svn log, but of how I  
would get revision/version numbers.  I tried piping svn log to grep  
with ''test'' as an argument.  Clearly that didn''t
work.  But even svn
log | grep test2spec didn''t give me revision numbers.

How would you have done it, if you were me?

Scott


On Jun 8, 2007, at 1:29 PM, David Chelimsky wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> On Jun 8, 2007, at 1:23 PM, David Chelimsky wrote:
>>
>>> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>>>>
>>>> On Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
>>>>
>>>>> On 6/8/07, Jonathan Linowes <jonathan at
parkerhill.com> wrote:
>>>>>> most plugins come with their own rails tests
>>>>>>
>>>>>> i''ve converted one by hand to rspec
(restful_authentication)
>>>>>> because
>>>>>> - its functionality is integral to my app
>>>>>> - its really a generator so the code ends up in my app
>>>>>> - there''s a good chance i''ll be
making custom changes to it as
>>>>>> my app
>>>>>> develops
>>>>>>
>>>>>> perhaps a tool that automatically converts rails tests
to rspecs
>>>>>> would be useful?
>>>>>
>>>>> We had one of those a while back. It was pretty good, but
not
>>>>> perfect.
>>>>> It''s very complex to get right and cover all the
possibilities and
>>>>> it''s something that we will likely not build as
part of rspec.
>>>>> That
>>>>> said, if somebody else wanted to create such a thing,
I''m sure
>>>>> you''d
>>>>> make a lot of people happy.
>>>>
>>>>
>>>> Wow.  That code must still be around somewhere in subversion
(any
>>>> hints as to it''s last release?)
>>>
>>> hint: svn log
>>
>> Sorry.  I wasn''t thinking.
>
> Please - no apology necessary. Just trying to teach a man to fish ....
>
> Cheers,
> David
>
>>
>> Scott
>>
>> _______________________________________________
>> 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 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
> Well, actually my problem wasn''t thinking of svn log, but of how I
> would get revision/version numbers.  I tried piping svn log to grep
> with ''test'' as an argument.  Clearly that didn''t
work.  But even svn
> log | grep test2spec didn''t give me revision numbers.
>
> How would you have done it, if you were me?
svn log > log
mate log

now search for test2spec - the revision number will be close by

The last one w/ test2spec in the comment is r621.

In http://rspec.rubyforge.org/changes.html, the last time test2spec is
mentioned is release 0.5.16. Note that that was back in the
days.of.dots.
>
> Scott
>
>
> On Jun 8, 2007, at 1:29 PM, David Chelimsky wrote:
>
> > On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
> >>
> >> On Jun 8, 2007, at 1:23 PM, David Chelimsky wrote:
> >>
> >>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
> >>>>
> >>>> On Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
> >>>>
> >>>>> On 6/8/07, Jonathan Linowes <jonathan at
parkerhill.com> wrote:
> >>>>>> most plugins come with their own rails tests
> >>>>>>
> >>>>>> i''ve converted one by hand to rspec
(restful_authentication)
> >>>>>> because
> >>>>>> - its functionality is integral to my app
> >>>>>> - its really a generator so the code ends up in my
app
> >>>>>> - there''s a good chance i''ll be
making custom changes to it as
> >>>>>> my app
> >>>>>> develops
> >>>>>>
> >>>>>> perhaps a tool that automatically converts rails
tests to rspecs
> >>>>>> would be useful?
> >>>>>
> >>>>> We had one of those a while back. It was pretty good,
but not
> >>>>> perfect.
> >>>>> It''s very complex to get right and cover all
the possibilities and
> >>>>> it''s something that we will likely not build
as part of rspec.
> >>>>> That
> >>>>> said, if somebody else wanted to create such a thing,
I''m sure
> >>>>> you''d
> >>>>> make a lot of people happy.
> >>>>
> >>>>
> >>>> Wow.  That code must still be around somewhere in
subversion (any
> >>>> hints as to it''s last release?)
> >>>
> >>> hint: svn log
> >>
> >> Sorry.  I wasn''t thinking.
> >
> > Please - no apology necessary. Just trying to teach a man to fish ....
> >
> > Cheers,
> > David
> >
> >>
> >> Scott
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Jun 8, 2007, at 1:44 PM, David Chelimsky wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> Well, actually my problem wasn''t thinking of svn log, but of
how I
>> would get revision/version numbers.  I tried piping svn log to grep
>> with ''test'' as an argument.  Clearly that
didn''t work.  But even svn
>> log | grep test2spec didn''t give me revision numbers.
>>
>> How would you have done it, if you were me?
>
> svn log > log
> mate log
>
> now search for test2spec - the revision number will be close by
>
My solution was something like the following:

svn log | grep test2spec -n  # for the line number
svn log | mate  # then searched for line number

Although after hanging out in #bash, I found a much better solution:

svn log | grep test2spec -B 3 | head

the -B 3 prints three lines before each entry.


Scott


> The last one w/ test2spec in the comment is r621.
>
> In http://rspec.rubyforge.org/changes.html, the last time test2spec is
> mentioned is release 0.5.16. Note that that was back in the
> days.of.dots.
>
>>
>> Scott
>>
>>
>> On Jun 8, 2007, at 1:29 PM, David Chelimsky wrote:
>>
>>> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>>>>
>>>> On Jun 8, 2007, at 1:23 PM, David Chelimsky wrote:
>>>>
>>>>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
>>>>>>
>>>>>> On Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
>>>>>>
>>>>>>> On 6/8/07, Jonathan Linowes <jonathan at
parkerhill.com> wrote:
>>>>>>>> most plugins come with their own rails tests
>>>>>>>>
>>>>>>>> i''ve converted one by hand to rspec
(restful_authentication)
>>>>>>>> because
>>>>>>>> - its functionality is integral to my app
>>>>>>>> - its really a generator so the code ends up in
my app
>>>>>>>> - there''s a good chance i''ll
be making custom changes to it as
>>>>>>>> my app
>>>>>>>> develops
>>>>>>>>
>>>>>>>> perhaps a tool that automatically converts
rails tests to
>>>>>>>> rspecs
>>>>>>>> would be useful?
>>>>>>>
>>>>>>> We had one of those a while back. It was pretty
good, but not
>>>>>>> perfect.
>>>>>>> It''s very complex to get right and cover
all the
>>>>>>> possibilities and
>>>>>>> it''s something that we will likely not
build as part of rspec.
>>>>>>> That
>>>>>>> said, if somebody else wanted to create such a
thing, I''m sure
>>>>>>> you''d
>>>>>>> make a lot of people happy.
>>>>>>
>>>>>>
>>>>>> Wow.  That code must still be around somewhere in
subversion (any
>>>>>> hints as to it''s last release?)
>>>>>
>>>>> hint: svn log
>>>>
>>>> Sorry.  I wasn''t thinking.
>>>
>>> Please - no apology necessary. Just trying to teach a man to  
>>> fish ....
>>>
>>> Cheers,
>>> David
>>>
>>>>
>>>> Scott
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
> On Jun 8, 2007, at 1:44 PM, David Chelimsky wrote:
>
> > On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
> >>
> >> Well, actually my problem wasn''t thinking of svn log, but
of how I
> >> would get revision/version numbers.  I tried piping svn log to
grep
> >> with ''test'' as an argument.  Clearly that
didn''t work.  But even svn
> >> log | grep test2spec didn''t give me revision numbers.
> >>
> >> How would you have done it, if you were me?
> >
> > svn log > log
> > mate log
> >
> > now search for test2spec - the revision number will be close by
> >
>
> My solution was something like the following:
>
> svn log | grep test2spec -n  # for the line number
> svn log | mate  # then searched for line number
>
> Although after hanging out in #bash, I found a much better solution:
>
> svn log | grep test2spec -B 3 | head
>
> the -B 3 prints three lines before each entry.
:)

Cool.
>
>
> Scott
>
>
>
> > The last one w/ test2spec in the comment is r621.
> >
> > In http://rspec.rubyforge.org/changes.html, the last time test2spec is
> > mentioned is release 0.5.16. Note that that was back in the
> > days.of.dots.
> >
> >>
> >> Scott
> >>
> >>
> >> On Jun 8, 2007, at 1:29 PM, David Chelimsky wrote:
> >>
> >>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
> >>>>
> >>>> On Jun 8, 2007, at 1:23 PM, David Chelimsky wrote:
> >>>>
> >>>>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
> >>>>>>
> >>>>>> On Jun 8, 2007, at 1:15 PM, David Chelimsky wrote:
> >>>>>>
> >>>>>>> On 6/8/07, Jonathan Linowes <jonathan at
parkerhill.com> wrote:
> >>>>>>>> most plugins come with their own rails
tests
> >>>>>>>>
> >>>>>>>> i''ve converted one by hand to
rspec (restful_authentication)
> >>>>>>>> because
> >>>>>>>> - its functionality is integral to my app
> >>>>>>>> - its really a generator so the code ends
up in my app
> >>>>>>>> - there''s a good chance
i''ll be making custom changes to it as
> >>>>>>>> my app
> >>>>>>>> develops
> >>>>>>>>
> >>>>>>>> perhaps a tool that automatically converts
rails tests to
> >>>>>>>> rspecs
> >>>>>>>> would be useful?
> >>>>>>>
> >>>>>>> We had one of those a while back. It was
pretty good, but not
> >>>>>>> perfect.
> >>>>>>> It''s very complex to get right and
cover all the
> >>>>>>> possibilities and
> >>>>>>> it''s something that we will likely
not build as part of rspec.
> >>>>>>> That
> >>>>>>> said, if somebody else wanted to create such a
thing, I''m sure
> >>>>>>> you''d
> >>>>>>> make a lot of people happy.
> >>>>>>
> >>>>>>
> >>>>>> Wow.  That code must still be around somewhere in
subversion (any
> >>>>>> hints as to it''s last release?)
> >>>>>
> >>>>> hint: svn log
> >>>>
> >>>> Sorry.  I wasn''t thinking.
> >>>
> >>> Please - no apology necessary. Just trying to teach a man to
> >>> fish ....
> >>>
> >>> Cheers,
> >>> David
> >>>
> >>>>
> >>>> Scott
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

I''ve been noticing recently that svn doesn''t always meet up to
expectations.  For instance, in copying directories:

svn mv dir1/ dir2

will move dir1 into dir2, not the contents of dir1 into dir2.  dir1/*  
doesn''t work either.


The exchange with David also shows that finding when a piece of  
software was removed from a project''s log is not a trivial task to do  
without a text editor present.

I wonder if it would be worth while developing some shell scripts to  
supplement SVN?

Scott



On Jun 8, 2007, at 2:46 PM, David Chelimsky wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> On Jun 8, 2007, at 1:44 PM, David Chelimsky wrote:
>>
>>> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>>>>
>>>> Well, actually my problem wasn''t thinking of svn log,
but of how I
>>>> would get revision/version numbers.  I tried piping svn log to
grep
>>>> with ''test'' as an argument.  Clearly that
didn''t work.  But even
>>>> svn
>>>> log | grep test2spec didn''t give me revision numbers.
>>>>
>>>> How would you have done it, if you were me?
>>>
>>> svn log > log
>>> mate log
>>>
>>> now search for test2spec - the revision number will be close by
>>>
>>
>> My solution was something like the following:
>>
>> svn log | grep test2spec -n  # for the line number
>> svn log | mate  # then searched for line number
>>
>> Although after hanging out in #bash, I found a much better solution:
>>
>> svn log | grep test2spec -B 3 | head
>>
>> the -B 3 prints three lines before each entry.
>
> :)
>
> Cool.
>
>>
>>
>> Scott
>>
>>
>>
>>> The last one w/ test2spec in the comment is r621.
>>>
>>> In http://rspec.rubyforge.org/changes.html, the last time  
>>> test2spec is
>>> mentioned is release 0.5.16. Note that that was back in the
>>> days.of.dots.
>>>
>>>>
>>>> Scott
>>>>
>>>>
>>>> On Jun 8, 2007, at 1:29 PM, David Chelimsky wrote:
>>>>
>>>>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
>>>>>>
>>>>>> On Jun 8, 2007, at 1:23 PM, David Chelimsky wrote:
>>>>>>
>>>>>>> On 6/8/07, Scott Taylor <mailing_lists at
railsnewbie.com> wrote:
>>>>>>>>
>>>>>>>> On Jun 8, 2007, at 1:15 PM, David Chelimsky
wrote:
>>>>>>>>
>>>>>>>>> On 6/8/07, Jonathan Linowes <jonathan at
parkerhill.com> wrote:
>>>>>>>>>> most plugins come with their own rails
tests
>>>>>>>>>>
>>>>>>>>>> i''ve converted one by hand to
rspec (restful_authentication)
>>>>>>>>>> because
>>>>>>>>>> - its functionality is integral to my
app
>>>>>>>>>> - its really a generator so the code
ends up in my app
>>>>>>>>>> - there''s a good chance
i''ll be making custom changes to
>>>>>>>>>> it as
>>>>>>>>>> my app
>>>>>>>>>> develops
>>>>>>>>>>
>>>>>>>>>> perhaps a tool that automatically
converts rails tests to
>>>>>>>>>> rspecs
>>>>>>>>>> would be useful?
>>>>>>>>>
>>>>>>>>> We had one of those a while back. It was
pretty good, but not
>>>>>>>>> perfect.
>>>>>>>>> It''s very complex to get right and
cover all the
>>>>>>>>> possibilities and
>>>>>>>>> it''s something that we will likely
not build as part of rspec.
>>>>>>>>> That
>>>>>>>>> said, if somebody else wanted to create
such a thing, I''m sure
>>>>>>>>> you''d
>>>>>>>>> make a lot of people happy.
>>>>>>>>
>>>>>>>>
>>>>>>>> Wow.  That code must still be around somewhere
in subversion
>>>>>>>> (any
>>>>>>>> hints as to it''s last release?)
>>>>>>>
>>>>>>> hint: svn log
>>>>>>
>>>>>> Sorry.  I wasn''t thinking.
>>>>>
>>>>> Please - no apology necessary. Just trying to teach a man
to
>>>>> fish ....
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
> I''ve been noticing recently that svn doesn''t always meet
up to
> expectations.  For instance, in copying directories:
>
> svn mv dir1/ dir2
>
> will move dir1 into dir2, not the contents of dir1 into dir2.  dir1/*
> doesn''t work either.
$ svn mv dir1/* dir2

that doesn''t move all dir1''s content to dir2?

Joe

On Jun 9, 2007, at 6:00 PM, Joe Van Dyk wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> I''ve been noticing recently that svn doesn''t always
meet up to
>> expectations.  For instance, in copying directories:
>>
>> svn mv dir1/ dir2
>>
>> will move dir1 into dir2, not the contents of dir1 into dir2.  dir1/*
>> doesn''t work either.
>
> $ svn mv dir1/* dir2
>
> that doesn''t move all dir1''s content to dir2?
If my memory recalls correctly, no, because the svn command can only  
handle one file at a time (so the shell substitution for ''*''
will
feed in all of the files, and svn will complain).

euclid% svn cp test/* something/
svn: Client error in parsing arguments

Also see this:

http://blog.caboo.se/articles/2005/12/16/svn-mv-dir

Scott

On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
> I wonder if it would be worth while developing some shell scripts to
> supplement SVN?
For what it''s worth, I''ll show you my svn aliases... but some
of them
are highly specific to my workflow, so I don''t really think
they''re
worth sharing around much:

http://pastie.caboo.se/69244

I never bothered to make a bash function to handle subversion move of
multiple files, but it wouldn''t be hard to do.  I just use the for
loop approach: "for i in src/*; do svn mv $i dest/; done".  I only
made aliases for the commands that I use often.

Of course, the various GUI clients make this sort of task much
simpler, too.  ;-)

-- 
Nick

On 6/10/07, nicholas a. evans <nick at ekenosen.net>
wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> > I wonder if it would be worth while developing some shell scripts to
> > supplement SVN?
>
> For what it''s worth, I''ll show you my svn aliases... but
some of them
> are highly specific to my workflow, so I don''t really think
they''re
> worth sharing around much:
>
> http://pastie.caboo.se/69244
Cool. Here''s another one I use all the time to see what files
I''ve
created that I haven''t added to svn.

snew() { svn st | awk ''/^\?/ {print $2}'' }

It prints a list of only the filenames, which you can then pipe to svn
add w/ xargs:

snew | xargs svn add

>
> I never bothered to make a bash function to handle subversion move of
> multiple files, but it wouldn''t be hard to do.  I just use the for
> loop approach: "for i in src/*; do svn mv $i dest/; done".  I
only
> made aliases for the commands that I use often.
>
> Of course, the various GUI clients make this sort of task much
> simpler, too.  ;-)
>
> --
> Nick
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>