[rspec-users] Rescuing a Test-Free Project with RSpec and Cucumber

David Kahn dk at structuralartistry.com
Sat Dec 11 13:27:28 EST 2010

On first thought what I would do since you have the project running in
production is to write all your Features and get them to pass on the
existing production application. That gives you a reality test on each piece
you change as you rebuilt. You have an additional challenge being in Rails 2
and wanting to go to Rails 3. I think if you want to do it gradually, start
with the Rails 2 project, write all Features and get them passing and then
rework the entire project gradually to completion in Rails 2. *Then* once
all this is done and everything is passing (Features/Functional/Unit tests),
then migrate it to Rails 3. Of course this might be harder and a bit more
time consuming than a full rewrite in Rails 3 but  you will gain the benefit
of shadowing a functional in-production project.

On Sat, Dec 11, 2010 at 11:47 AM, Shea Levy <shea at shealevy.com> wrote:

> Hi all,
> I was recently brought onto a Rails 2.2.3 project which was itself an
> emergency rescue of a spaghetti-coded PHP project (complete with hard-coded
> SQL statements!). Due to the fact that the code was already in production
> and has required fairly constant maintenance and feature additions, the dev
> who switched everything over to Rails hasn't written a single test. The
> eventual goal, the achievement of which is one of my primary
> responsibilities on the project, is to have the project be migrated to Rails
> 3, fully spec'd at all levels and documented at the top level with Cucumber
> features, matching Rails conventions (e.g. the database table for the Shop
> model is currently 'shops_master' and will eventually be 'shops') and with
> all vestiges of the original project completely removed (there's still some
> PHP code running on the production site). My question is: what's the best
> approach to get from here to there? Is it possible to do this gradually
> while development continues on the current project, or is a total refresh
> going to be necessary? I'd much prefer a gradual approach because the other
> dev on the project is working full-time on adding features to and
> maintaining the current site and all of my responsibilities outside of the
> migration will be focused on adding features to the current site, so if I
> were to do a complete refresh any work from here on out would be completely
> duplicated. Additionally, the other dev on the project (who has much more
> general coding experience than I do) won't be able to spare time to help me
> out with problems on a refresh the way he would if any gradual changes were
> implemented on the current project. The only problem with the gradual
> approach is that I have no idea how to actually do it! Do I start with
> unit-tests of the already-existing code and work my way out to features, or
> do I start with features describing things already implemented and work my
> way in? Do I try to convince the other dev to start outside-in with all new
> features now, or do I wait until I've done more with what's already there?
> Are there any good resources out there for tasks like this? Also, if a
> refresh IS necessary: what's the best way to go about replicating the
> functionality of an existing project?
> tl;dr: Is it possible to save a test-free project via gradual steps, or is
> a complete refresh necessary? If the former, how do I go about doing that?
> If the latter, how do I do it in a way that keeps overall functionality of
> the resulting project the same as the original?
> Cheers,
> Shea Levy
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20101211/8006bd76/attachment-0001.html>

More information about the rspec-users mailing list