[rspec-users] Four Question From an RSpec Baby - Give me something to chew
mailing_lists at railsnewbie.com
Wed Aug 27 23:46:03 EDT 2008
On Aug 27, 2008, at 2:40 PM, Matt Wynne wrote:
> I have another, more general tip - read this book:
> Michael's definition of Legacy Code is simply 'code that isn't
> covered by tests'. So... err... that would be your whole app!
Well - I think it was zenspider who said legacy code is code either:
1) you didn't write, or 2) you didn't *just* write 20 minutes ago.
There is something to it.
> The book suggests chipping away at the lack of test coverage by
> writing tests (or specs) when you
> - change code to add a feature
> - need to fix a bug (write a test / spec that fails because of the
> bug... fix the bug... high five)
With my last job, I inherited an 8000 line rails code base with 30
Test::Unit tests, 25 of which were failing. I decided to delete
those, and start a fresh with test suite (under rspec, of course).
Over a few months, without ever going out of my way to write specs for
legacy code, I had over over 80% coverage (if I remember correctly).
Just chip away as you would normally, and sooner or later the crap
code gets replaced. Don't get overwhelmed by rcov. Just write specs
for everything *you* write, and write specs for anything else you
touch. Especially regressions. Usually you can get in a few extra
specs when writing a regression that has nothing to do with the bug
itself (it's a sort of testing after the fact - almost like proving
theorems of an existing system).
Honestly, you won't have time to write new specs - it's frustrating /
painful to write specs *after* code, and so it doesn't usually get
done (since it's not any fun). Just chip away gradually and you'll
get there eventually. If you're really eager to go off and write
extra specs, just write really clear specs and then show the HTML
specdocs to your boss - he'll probably appreciate it, especially if
formal specs hadn't been drafted up previously.
More information about the rspec-users