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
David Chelimsky
2007-Sep-16 19:04 UTC
[rspec-users] [ANN] rspec_todo -- spec''ing backwards
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
lancecarlson at gmail.com
2007-Sep-17 04:14 UTC
[rspec-users] [ANN] rspec_todo -- spec''ing backwards
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
Mark Van De Vyver
2007-Sep-17 06:30 UTC
[rspec-users] [ANN] rspec_todo -- spec''ing backwards
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 useI 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
David Chelimsky
2007-Sep-18 09:41 UTC
[rspec-users] [ANN] rspec_todo -- spec''ing backwards
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