rspec users - Apr 2009 - Cucumber/RSpec for an existing Rails project - generate rspec models and controllers?

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:   lee_longmore at yahoo.co.uk



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20090426/b585e7e3/attachment.html>

On Sun, Apr 26, 2009 at 1:47 AM, Lee Longmore <lee_longmore at
yahoo.co.uk> wrote:
>
> 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 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
>
> Many thanks,
>
> Lee.
>
> mobile: +44(0)775 392 8067
> home: +44(0) 208 8358256
> email:?? lee_longmore at yahoo.co.uk
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>