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 <s...@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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
