Forum: RSpec Cucumber/RSpec for an existing Rails project - generate rspec models and controllers?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Lee L. (Guest)
on 2009-04-26 10:59
(Received via mailing list)
Hi,

I would like to use Cucumber and RSpec for my existing Rails project.

I am now reasonably comfortable with the use of these, having studied
the RSpec Book and various online resources. I am however unsure about
one thing...

Given that I have several existing models and controllers in my code
base, 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 so, is there I anything I should be aware of when doing so?

Many thanks,

Lee.


mobile: +44(0)775 392 8067
home: +44(0) 208 8358256
email:   removed_email_address@domain.invalid
David C. (Guest)
on 2009-04-26 13:34
(Received via mailing list)
On Sun, Apr 26, 2009 at 1:47 AM, Lee L. <removed_email_address@domain.invalid>
wrote:
> 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).

Cheers,
David
This topic is locked and can not be replied to.