[rspec-users] [ANN] rspec_todo -- spec'ing backwards
dchelimsky at gmail.com
Tue Sep 18 05:41:30 EDT 2007
On 9/17/07, s.ross <cwdinfo at gmail.com> wrote:
> 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
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.
> 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.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users