rspec users - Sep 2007 - rspec_todo -- spec''ing backwards

While the spirit of BDD is to spec first and code second, many of us  
have legacy code. Worse, some of us have legacy code without very  
good coverage. Recognizing that *I* have such code, I created a  
script that grinds through your .rb files and creates placeholder  
specs for each public method.

While it is more sensible to spec behavior of code function than of  
individual methods, this tool can help jump start a transition to  
that wonderful place. Comments welcome (and please be kind about the  
code -- I know it needs refactoring :).

svn:

http://svn.calicowebdev.com/rspec_todo/trunk

Excerpt from the readme:

Usage is:

   ruby spec_todo.rb <options> <files>

Options are:

   -m -- Wrap each file''s spec in a module

   -u -- Use "it" with a block and a pending method rather than a
"it"


So, for example, I might use it as follows:

   ruby spec_todo.rb app/models/* app/controllers/*

Here is a brief example of the output of this tool:


       #------------------------------------------------------------
       # File: app/controllers/contact_controller_spec.rb
       #------------------------------------------------------------

       require File.dirname(__FILE__) + ''/../spec_helper''

       describe "A ContactController" do
         it "should do something sensible with index."
         it "should do something sensible with thank_you."
       end

On 9/16/07, s.ross <cwdinfo at gmail.com> wrote:
> While the spirit of BDD is to spec first and code second, many of us
> have legacy code. Worse, some of us have legacy code without very
> good coverage. Recognizing that *I* have such code, I created a
> script that grinds through your .rb files and creates placeholder
> specs for each public method.
>
> While it is more sensible to spec behavior of code function than of
> individual methods, this tool can help jump start a transition to
> that wonderful place. Comments welcome (and please be kind about the
> code -- I know it needs refactoring :).
>
> svn:
>
> http://svn.calicowebdev.com/rspec_todo/trunk
>
> Excerpt from the readme:
>
> Usage is:
>
>    ruby spec_todo.rb <options> <files>
>
> Options are:
>
>    -m -- Wrap each file''s spec in a module
>
>    -u -- Use "it" with a block and a pending method rather than a
"it"
>
>
> So, for example, I might use it as follows:
>
>    ruby spec_todo.rb app/models/* app/controllers/*
>
> Here is a brief example of the output of this tool:
>
>
>        #------------------------------------------------------------
>        # File: app/controllers/contact_controller_spec.rb
>        #------------------------------------------------------------
>
>        require File.dirname(__FILE__) + ''/../spec_helper''
>
>        describe "A ContactController" do
>          it "should do something sensible with index."
>          it "should do something sensible with thank_you."
>        end
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Jim Weirich has a great article where he uses a technique to retrofit
legacy code with specs.
http://onestepback.org/index.cgi/Tech/Ruby/FlexMockAndFluidDynamics.red

Pat

On 9/16/07, s.ross <cwdinfo at gmail.com> wrote:
> While the spirit of BDD is to spec first and code second, many of us
> have legacy code. Worse, some of us have legacy code without very
> good coverage. Recognizing that *I* have such code, I created a
> script that grinds through your .rb files and creates placeholder
> specs for each public method.
>
> While it is more sensible to spec behavior of code function than of
> individual methods, this tool can help jump start a transition to
> that wonderful place.
Hi Steve,

There are tools that will do this for you on java projects and in
nearly every case that I''ve seen them used, the result has been 100
line test methods, one per object method, that take the object through
multiple states, become impossible to understand, and often just get
commented out.

Worse, even though you sell it as a tool for dealing with legacy code
(code without tests), it will end up becoming the tool people use and,
even worse than that, they''ll think it''s BDD because it
creates specs
and not tests.

I beg you (I''m on my knees as I''m writing this) to throw this
manuscript in the fire now!

FWIW,
David
> Comments welcome (and please be kind about the
> code -- I know it needs refactoring :).
>
> svn:
>
> http://svn.calicowebdev.com/rspec_todo/trunk
>
> Excerpt from the readme:
>
> Usage is:
>
>    ruby spec_todo.rb <options> <files>
>
> Options are:
>
>    -m -- Wrap each file''s spec in a module
>
>    -u -- Use "it" with a block and a pending method rather than a
"it"
>
>
> So, for example, I might use it as follows:
>
>    ruby spec_todo.rb app/models/* app/controllers/*
>
> Here is a brief example of the output of this tool:
>
>
>        #------------------------------------------------------------
>        # File: app/controllers/contact_controller_spec.rb
>        #------------------------------------------------------------
>
>        require File.dirname(__FILE__) + ''/../spec_helper''
>
>        describe "A ContactController" do
>          it "should do something sensible with index."
>          it "should do something sensible with thank_you."
>        end
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Sep 16, 2007, at 3:04 PM, David Chelimsky wrote:
> On 9/16/07, s.ross <cwdinfo at gmail.com> wrote:
>> While the spirit of BDD is to spec first and code second, many of us
>> have legacy code. Worse, some of us have legacy code without very
>> good coverage. Recognizing that *I* have such code, I created a
>> script that grinds through your .rb files and creates placeholder
>> specs for each public method.
>>
>> While it is more sensible to spec behavior of code function than of
>> individual methods, this tool can help jump start a transition to
>> that wonderful place.
>
> Hi Steve,
>
> There are tools that will do this for you on java projects and in
> nearly every case that I''ve seen them used, the result has been
100
> line test methods, one per object method, that take the object through
> multiple states, become impossible to understand, and often just get
> commented out.
>
> Worse, even though you sell it as a tool for dealing with legacy code
> (code without tests), it will end up becoming the tool people use and,
> even worse than that, they''ll think it''s BDD because it
creates specs
> and not tests.
>
> I beg you (I''m on my knees as I''m writing this) to throw
this
> manuscript in the fire now!

I agree with David (you can also look at the ZenTest suite, which has  
a similar tool).  I haven''t looked at the tool, but how about  
modifying it to create comments in the specs, somthing like this:

# You haven''t specified the behaviour of User#method1!
# You haven''t specified the behaviour of User#method2!

Scott

On 9/16/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
> On Sep 16, 2007, at 3:04 PM, David Chelimsky wrote:
>
> > On 9/16/07, s.ross <cwdinfo at gmail.com> wrote:
> >> While the spirit of BDD is to spec first and code second, many of
us
> >> have legacy code. Worse, some of us have legacy code without very
> >> good coverage. Recognizing that *I* have such code, I created a
> >> script that grinds through your .rb files and creates placeholder
> >> specs for each public method.
> >>
> >> While it is more sensible to spec behavior of code function than
of
> >> individual methods, this tool can help jump start a transition to
> >> that wonderful place.
> >
> > Hi Steve,
> >
> > There are tools that will do this for you on java projects and in
> > nearly every case that I''ve seen them used, the result has
been 100
> > line test methods, one per object method, that take the object through
> > multiple states, become impossible to understand, and often just get
> > commented out.
> >
> > Worse, even though you sell it as a tool for dealing with legacy code
> > (code without tests), it will end up becoming the tool people use and,
> > even worse than that, they''ll think it''s BDD because
it creates specs
> > and not tests.
> >
> > I beg you (I''m on my knees as I''m writing this) to
throw this
> > manuscript in the fire now!
>
>
> I agree with David (you can also look at the ZenTest suite, which has
> a similar tool).  I haven''t looked at the tool, but how about
> modifying it to create comments in the specs, somthing like this:
>
> # You haven''t specified the behaviour of User#method1!
> # You haven''t specified the behaviour of User#method2!
>
> Scott
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Why not use RCov?  Seeing a bunch of red is a much bigger motivator
than a lame comment.

Pat

>>
>>
>> I agree with David (you can also look at the ZenTest suite, which has
>> a similar tool).  I haven''t looked at the tool, but how about
>> modifying it to create comments in the specs, somthing like this:
>>
>> # You haven''t specified the behaviour of User#method1!
>> # You haven''t specified the behaviour of User#method2!
>>
>> Scott
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> Why not use RCov?  Seeing a bunch of red is a much bigger motivator
> than a lame comment.
Good point.

Just out of curiosity - Have you noticed that rcov won''t pick up all  
of the files in a Rails project unless there is an explicit spec file  
for it (or the class/model isn''t called) ?

Scott

As with all development tools, caveat programmer. The art is in  
recognizing the behaviors and not just exercising the methods  
meaninglessly. I personally believe that having the method tests in  
spec form allows me to think about what the methods are *doing* and  
then write the real behavior I expect. This is not -- for me -- a  
"let''s get 100% coverage" exercise. Just another tool that
might be
of use.

By the way, do you find that typing when on your knees helps your  
posture? I thought about that for a while but found I prefer sitting  
in a chair as I write :)

--steve

On Sep 16, 2007, at 12:04 PM, David Chelimsky wrote:
> On 9/16/07, s.ross <cwdinfo at gmail.com> wrote:
>> While the spirit of BDD is to spec first and code second, many of us
>> have legacy code. Worse, some of us have legacy code without very
>> good coverage. Recognizing that *I* have such code, I created a
>> script that grinds through your .rb files and creates placeholder
>> specs for each public method.
>>
>> While it is more sensible to spec behavior of code function than of
>> individual methods, this tool can help jump start a transition to
>> that wonderful place.
>
> Hi Steve,
>
> There are tools that will do this for you on java projects and in
> nearly every case that I''ve seen them used, the result has been
100
> line test methods, one per object method, that take the object through
> multiple states, become impossible to understand, and often just get
> commented out.
>
> Worse, even though you sell it as a tool for dealing with legacy code
> (code without tests), it will end up becoming the tool people use and,
> even worse than that, they''ll think it''s BDD because it
creates specs
> and not tests.
>
> I beg you (I''m on my knees as I''m writing this) to throw
this
> manuscript in the fire now!
>
> FWIW,
> David
>
>> Comments welcome (and please be kind about the
>> code -- I know it needs refactoring :).
>>
>> svn:
>>
>> http://svn.calicowebdev.com/rspec_todo/trunk
>>
>> Excerpt from the readme:
>>
>> Usage is:
>>
>>    ruby spec_todo.rb <options> <files>
>>
>> Options are:
>>
>>    -m -- Wrap each file''s spec in a module
>>
>>    -u -- Use "it" with a block and a pending method rather
than a
>> "it"
>>
>>
>> So, for example, I might use it as follows:
>>
>>    ruby spec_todo.rb app/models/* app/controllers/*
>>
>> Here is a brief example of the output of this tool:
>>
>>
>>        #------------------------------------------------------------
>>        # File: app/controllers/contact_controller_spec.rb
>>        #------------------------------------------------------------
>>
>>        require File.dirname(__FILE__) +
''/../spec_helper''
>>
>>        describe "A ContactController" do
>>          it "should do something sensible with index."
>>          it "should do something sensible with thank_you."
>>        end
>>
>> _______________________________________________
>> 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

Yes that is nice because you know what files aren''t really being used.
That is asiming you tested everything that is being used!
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Scott Taylor <mailing_lists at railsnewbie.com>

Date: Sun, 16 Sep 2007 15:45:34 
To:rspec-users <rspec-users at rubyforge.org>
Subject: Re: [rspec-users] [ANN] rspec_todo -- spec''ing backwards

>>
>>
>> I agree with David (you can also look at the ZenTest suite, which has
>> a similar tool).  I haven''t looked at the tool, but how about
>> modifying it to create comments in the specs, somthing like this:
>>
>> # You haven''t specified the behaviour of User#method1!
>> # You haven''t specified the behaviour of User#method2!
>>
>> Scott
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> Why not use RCov?  Seeing a bunch of red is a much bigger motivator
> than a lame comment.
Good point.

Just out of curiosity - Have you noticed that rcov won''t pick up all  
of the files in a Rails project unless there is an explicit spec file  
for it (or the class/model isn''t called) ?

Scott

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

Hi,
On 9/17/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 9/16/07, s.ross <cwdinfo at gmail.com> wrote:
> > While the spirit of BDD is to spec first and code second, many of us
> > have legacy code. Worse, some of us have legacy code without very
> > good coverage. Recognizing that *I* have such code, I created a
> > script that grinds through your .rb files and creates placeholder
> > specs for each public method.
> >
> > While it is more sensible to spec behavior of code function than of
> > individual methods, this tool can help jump start a transition to
> > that wonderful place.
>
> Hi Steve,
>
> There are tools that will do this for you on java projects and in
> nearly every case that I''ve seen them used, the result has been
100
> line test methods, one per object method, that take the object through
> multiple states, become impossible to understand, and often just get
> commented out.
>
> Worse, even though you sell it as a tool for dealing with legacy code
> (code without tests), it will end up becoming the tool people use and,
> even worse than that, they''ll think it''s BDD because it
creates specs
> and not tests.
>
> I beg you (I''m on my knees as I''m writing this) to throw
this
> manuscript in the fire now!
Hmm, I''ve never heard of this approach (burning stuff) ending in joy...
Perhaps what you''d like is a one line comment to be prepended to each
spec file pointing to spec best/good practice?
I''d nominate someone''s(;) ) ''One expectation per
example'' page:
http://rubyurl.com/2jw
For example:
# Visit the following page for an excellent illustration of how to specify code:
# http://rubyurl.com/2jw

Or, you might prefer that any newbie sees that for each method there
are multiple ''it''s'' prepared? Or maybe the template
pending text
should read:
"should specify one expectation per example"

Given these are just clutter things for some expert who is extending
existing code using a BDD approach, and they just want a skeleton of
''what''s in there'', you might ask for an
''-e''xpert switch that turns
these defaults off.

Would that advance anything?

My 2c.


> FWIW,
> David
>
> > Comments welcome (and please be kind about the
> > code -- I know it needs refactoring :).
> >
> > svn:
> >
> > http://svn.calicowebdev.com/rspec_todo/trunk
> >
> > Excerpt from the readme:
> >
> > Usage is:
> >
> >    ruby spec_todo.rb <options> <files>
> >
> > Options are:
> >
> >    -m -- Wrap each file''s spec in a module
> >
> >    -u -- Use "it" with a block and a pending method rather
than a "it"
> >
> >
> > So, for example, I might use it as follows:
> >
> >    ruby spec_todo.rb app/models/* app/controllers/*
> >
> > Here is a brief example of the output of this tool:
> >
> >
> >        #------------------------------------------------------------
> >        # File: app/controllers/contact_controller_spec.rb
> >        #------------------------------------------------------------
> >
> >        require File.dirname(__FILE__) +
''/../spec_helper''
> >
> >        describe "A ContactController" do
> >          it "should do something sensible with index."
> >          it "should do something sensible with thank_you."
> >        end
> >
> > _______________________________________________
> > 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 9/16/07, Mark Van De Vyver <mvyver at gmail.com>
wrote:
>
> Hi,
> On 9/17/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 9/16/07, s.ross <cwdinfo at gmail.com> wrote:
> > > While the spirit of BDD is to spec first and code second, many of
us
> > > have legacy code. Worse, some of us have legacy code without very
> > > good coverage. Recognizing that *I* have such code, I created a
> > > script that grinds through your .rb files and creates placeholder
> > > specs for each public method.
> > >
> > > While it is more sensible to spec behavior of code function than
of
> > > individual methods, this tool can help jump start a transition to
> > > that wonderful place.
> >
> > Hi Steve,
> >
> > There are tools that will do this for you on java projects and in
> > nearly every case that I''ve seen them used, the result has
been 100
> > line test methods, one per object method, that take the object through
> > multiple states, become impossible to understand, and often just get
> > commented out.
> >
> > Worse, even though you sell it as a tool for dealing with legacy code
> > (code without tests), it will end up becoming the tool people use and,
> > even worse than that, they''ll think it''s BDD because
it creates specs
> > and not tests.
> >
> > I beg you (I''m on my knees as I''m writing this) to
throw this
> > manuscript in the fire now!
>
> Hmm, I''ve never heard of this approach (burning stuff) ending in
joy...
> Perhaps what you''d like is a one line comment to be prepended to
each
> spec file pointing to spec best/good practice?
> I''d nominate someone''s(;) ) ''One expectation per
example'' page:
> http://rubyurl.com/2jw
> For example:
> # Visit the following page for an excellent illustration of how to specify
> code:
> # http://rubyurl.com/2jw
>
> Or, you might prefer that any newbie sees that for each method there
> are multiple ''it''s'' prepared? Or maybe the
template pending text
> should read:
> "should specify one expectation per example"
>
> Given these are just clutter things for some expert who is extending
> existing code using a BDD approach, and they just want a skeleton of
> ''what''s in there'', you might ask for an
''-e''xpert switch that turns
> these defaults off.
>
> Would that advance anything?
>
> My 2c.

Hey,

Just joined the list less than an hour ago, but I''ve been using RSpec
consistently since May. This looks like an interesting topic, and thought
I''d chime in. I''m currently working with a crapload of legacy
code. But it''s
not in Ruby. It''s in Visual Basic. Not quite the same issue, but
similar in
some ways. For the most part, I''m completely ignoring all the old code.
The
business logic, the part of the code that actually matters, is what I try to
fish out, and run tests against. If that legacy code is just
presentation/controller/database logic, don''t loose sleep over it. But
don''t
take my word for it. Here''s a few other opinions:

http://www.slideshare.net/rabble/testing-legacy-rails-apps/

Not sure who this guy is, but I guess this was presented at RailsConf
''07.
He suggests just testing when bugs are found, or when refactoring needs to
be done. Otherwise, you might waste your time.

http://gilesbowkett.blogspot.com/2007/08/getting-legacy-code-under-test.html

My boy Giles Bowkett has a completed opposite take: Do a manual
"heckle" on
all that legacy code, and find out what''s necessary and what''s
not. I
probably wouldn''t bother doing this by hand, but if you want something
more
solid that just fishing out bugs, I''d suppose this would work.

-Rob

> FWIW,
> > David
> >
> > > Comments welcome (and please be kind about the
> > > code -- I know it needs refactoring :).
> > >
> > > svn:
> > >
> > > http://svn.calicowebdev.com/rspec_todo/trunk
> > >
> > > Excerpt from the readme:
> > >
> > > Usage is:
> > >
> > >    ruby spec_todo.rb <options> <files>
> > >
> > > Options are:
> > >
> > >    -m -- Wrap each file''s spec in a module
> > >
> > >    -u -- Use "it" with a block and a pending method
rather than a "it"
> > >
> > >
> > > So, for example, I might use it as follows:
> > >
> > >    ruby spec_todo.rb app/models/* app/controllers/*
> > >
> > > Here is a brief example of the output of this tool:
> > >
> > >
> > >       
#------------------------------------------------------------
> > >        # File: app/controllers/contact_controller_spec.rb
> > >       
#------------------------------------------------------------
> > >
> > >        require File.dirname(__FILE__) +
''/../spec_helper''
> > >
> > >        describe "A ContactController" do
> > >          it "should do something sensible with index."
> > >          it "should do something sensible with
thank_you."
> > >        end
> > >
> > > _______________________________________________
> > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070916/44d95c8a/attachment-0001.html

David--
> Worse, even though you sell it as a tool for dealing with legacy code
> > (code without tests), it will end up becoming the tool people use
I think this is the part that is of the most concern. That people  
will substitute a tool for good judgment. That should not reflect  
poorly on BDD or rSpec. It just is what it is. ZenTest has an  
analogous facility and I don''t think it does a particularly better  
job of pulling out stuff to test, nor does it (IMO) decrease the  
value or legitimacy of TDD or ZenTest. Whoever wants to use it does,  
and others ignore it.

Reading the posts on this list, it seems to me that most posters have  
grokked the BDD idea and would be writing their examples first and  
describing behaviors. Most, if not all, will spot where their specs  
don''t align with methods, but rather with a combination of method  
invocations. Rcov is, of course, an invaluable tool for discovering  
which lines of code simply haven''t been run. But, as with all tools,  
Rcov only gives you the feedback on whether the code was run, not  
whether your example made sense or whether multiple branches were  
exercised.

My goal -- and it''s worked for me -- was to find a way to break the  
inertia of having no specs (clients with legacy code that appears to  
work aren''t always keen to pay for writing specs) and make me puzzle  
out which things make sense to spec as behaviors and which are really  
only helpers (and thus candidates to move into private visibility).

I''m not planning to dump much more time into this tool unless there  
is a compelling reason to do so, but it''s another arrow (perhaps a  
bent one :) in the quiver.

--steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070917/731294b8/attachment.html

On 9/17/07, s.ross <cwdinfo at gmail.com> wrote:
> David--
>
> Worse, even though you sell it as a tool for dealing with legacy code
> > (code without tests), it will end up becoming the tool people use
> I think this is the part that is of the most concern. That people will
> substitute a tool for good judgment. That should not reflect poorly on BDD
> or rSpec. It just is what it is. ZenTest has an analogous facility and I
> don''t think it does a particularly better job of pulling out stuff
to test,
> nor does it (IMO) decrease the value or legitimacy of TDD or ZenTest.
> Whoever wants to use it does, and others ignore it.
>
> Reading the posts on this list, it seems to me that most posters have
> grokked the BDD idea and would be writing their examples first and
> describing behaviors. Most, if not all, will spot where their specs
don''t
> align with methods, but rather with a combination of method invocations.
> Rcov is, of course, an invaluable tool for discovering which lines of code
> simply haven''t been run. But, as with all tools, Rcov only gives
you the
> feedback on whether the code was run, not whether your example made sense
or
> whether multiple branches were exercised.
>
> My goal -- and it''s worked for me -- was to find a way to break
the inertia
> of having no specs (clients with legacy code that appears to work
aren''t
> always keen to pay for writing specs) and make me puzzle out which things
> make sense to spec as behaviors and which are really only helpers (and thus
> candidates to move into private visibility).
I tend to approach the whole legacy thing (any code w/ no tests) from
the view espoused by Michael Feathers in his book Working Effectively
with Legacy Code: when you want to add a feature or change behaviour,
you discover where you want to make the change, analyze the parts of
the code it will impact, and add characterization tests for those
areas only. This way you''re always working on stuff that has immediate
value and , little by little, you move towards a very well covered
system.

As you suggest, no client wants to pay for testing stuff that they see
as already working - but certainly they don''t you want you to break
that stuff either.

Cheers,
David
> I''m not planning to dump much more time into this tool unless
there is a
> compelling reason to do so, but it''s another arrow (perhaps a bent
one :) in
> the quiver.
>
> --steve
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

>
> I tend to approach the whole legacy thing (any code w/ no tests) from
> the view espoused by Michael Feathers in his book Working Effectively
> with Legacy Code: when you want to add a feature or change behaviour,
> you discover where you want to make the change, analyze the parts of
> the code it will impact, and add characterization tests for those
> areas only. This way you''re always working on stuff that has
immediate
> value and , little by little, you move towards a very well covered
> system.
>
> As you suggest, no client wants to pay for testing stuff that they see
> as already working - but certainly they don''t you want you to
break
> that stuff either.
>
> Cheers,
> David
+1 => This is exactly how I''ve been approaching it with a 10,000
line
rails app with virtually no tests.

Scott