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 <[EMAIL PROTECTED]> 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@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
