Working on a legacy Rails application

Question

I have a very old and poorly written Rails app. There are about 9000 lines of code and zero tests. Most of the code is in controllers, and even worse, there are tons of external API calls, system calls to random scripts, etc.

There is also no development environment, everything is set up to work against the production databases. Well not just one database, there are about 10 different databases, since the app is kind of admin backend for a larger site.

My first idea was to get at least somewhat decent test coverage around the parts that I'm going to work on, but I'm unable to get the thing working anywhere else than on the production servers.

Also there are tons of old gems and deprecated warnings, but I can't even think about upgrading the gems until there are tests. Rewrite of the whole up is not an option, and I'm going to have to add/change stuff soon.

I'm not really sure how to approach testing such an app, since there's just so much stuff that can go wrong. What I'd really like to do, is to write some integration tests and then start refactoring, but I can't do that on a production environment.

Writing unit tests with bunch of stubs and mocks doesn't seem that helpful, since the code I'm going to work on basically has to be rewritten from scratch.

What are some steps I can take to basically duplicate a hugeass complex production environment on my development machine, so I can do stuff in isolation?

edit: A little fun fact about the app. When I tried to run it for the first time, it kept on freezing without any error messages ... until about a half hour later I found out, that the timeout to connecting to a database (which wasn't available) was set to 90 minutes!

Answer 1

So this is a relatively new / rare occurrence, because rails "LEGACY" applications are not too popular yet (still pretty young).

However, I have come across a few different writings about how to test (untested) legacy rails applications. A few that I recommend are:

1. This slideshare
2. Chapter 18 of "Rails Test Presciptions" from Pragmatic Programmers.

The ultimate and most important thing is to get SOME sort of a test harness working. This means getting factories working, getting your test database working, getting rake running (even if that means stripping out broken tests). From that point, you go back and test modules as you need them, as well as MAKING SURE you are testing all new pieces of code you add to the project.

This is a hugely painful task, and I applaud you for looking to do it the right way.

Cheers!

Answer 2

I worked on several rescue missions, mostly PHP projects that were really bad, but not only - desperate product owners left by bad 80% programmers pay nice to finish their abandoned projects :) .

• My approach is to use brute force.
• Start it in development and fix things until you get it running, by means of sheer power - fix, try, fix, try.
• You will get it working eventually.
• 9000 lines of code is not much code, I'd say it's reasonable size for bad legacy code, it could had been a lot worse.
• Start refactoring slowly bit by bit.
• These task will need time, so don't expect it to happen at once.