[rspec-users] [ANN] rspec_todo -- spec'ing backwards

Farley Knight farleyknight at gmail.com
Mon Sep 17 02:55:30 EDT 2007


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 


More information about the rspec-users mailing list