On Sun, Apr 26, 2009 at 1:47 AM, Lee L. email@example.com
how do I synch RSpec with these?
That is, do I need to generate RSpec models and controllers for each of
these existing models and controllers?
If you already have code in place, I would recommend adding specs by
hand instead of using the generators.
If so, is there I anything I should be aware of when doing so?
Back-filling specs onto pre-existing code is a very different animal
from driving out code with specs first. There is a book called Working
Effectively with Legacy Code by Michael Feathers that deals with this
topic very thoroughly. You might not think what you have is legacy
code, but Michael (actually, Erik Meade, but in the WELC book),
defines legacy code as any code without tests.
Part of the premise of TDD (with a T) is that by writing tests and
code in a tight cycle (small bit of test, small bit of code to make it
pass, refactor), the resulting code is inherently testable. When
you’re backfilling tests, this is not necessarily the case. So the
trick is to add the tests slowly, and pay attention to the code as
you’re doing so. If something is hard to test then use the opportunity
to make it easier to test.
Of course doing so is refactoring without tests, which is something to
be avoided. So you’ve got a catch 22. And that’s where the legacy code
book can really help, as it offers a number of techniques and
strategies to address this problem. So I’d recommend picking that up.
Short of buying the book, the basic idea is that whenever you’re
modifying your existing code, find all the high level features that
might be impacted and add cucumber scenarios for them first. Once
those are in place, drive out the changes and/or new code spec first.
With this strategy, you’ll gradually improve the code base by getting
it under test and refactoring as you go. This is more pain-staking
than doing a one-time full coverage sort of thing, but in the end the
result is going to be cleaner and better for you (and probably less
work in the long run).