[rspec-users] Rescuing a Test-Free Project with RSpec and Cucumber
dchelimsky at gmail.com
Sat Dec 11 13:24:33 EST 2010
On Dec 11, 2010, at 11:47 AM, Shea Levy 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?
> Shea Levy
There's a great book by Michael Feathers called "Working Effectively with Legacy Code," in which he defines legacy code as code without tests. The examples are mostly in C++ and Java, but many of the concepts are technology-independent.
The short version is: do it gradually. Start with a "characterization" test (generally end to end tests, probably using Cucumber) that describes an existing feature and covers the parts of the code you're about to change for a new feature. Feathers' book provides strategies for figuring out what to test in characterization tests.
Once you've got the coverage you think you need to get you safely through a feature you're about to write, then drive it out using whatever process you would normally use on a well tested app.
If you do this consistently as you add new features, you'll build up a meaningful suite pretty quickly.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users