Upgrading a Rails application can be complex, but knowledge is power. Knowledge of tool changes, deprecations at specific versions, and general upgrade pain points can all help anticipate and prepare for a smooth upgrade. Perhaps one of the most critical pieces of information is whether or not upgrading a tool affected your application.
A robust test suite will tell you if your application is working as it did before upgrades and good test coverage can help find inconsistencies in the upgrade before your user does.
Upgrading, even with appropriate test coverage, can be a significant undertaking for any dev team. Still, the value gained here is that the problems will present themselves, and it’s much easier to estimate time, effort, and resources effectively. When you bump up a gem, and the test suite passes, you can move forward to the next gem or the next version with confidence and a happy heart.
If the test suite or specific tests fail, you’ll likely have specific errors that can guide particular changes. It’s a much more linear and self-guiding process with limited unwanted surprises.
Insufficient test coverage, on the other hand, can lead to an upgrade that’s more difficult and unpredictable than needed. Let’s say, for example, you’re upgrading something significant like Ruby or RSpec to a major version change where the tool’s changelog details breaking changes: bundle update, no deprecation warnings.
Cool.
Test suite passes.
Cool ...wait, what?
This is a difficult situation. When you don’t have tests covering a breaking change, it can take additional time and resources to understand the change, locate where it could have been used in the code, and refactor or re-write it appropriately. Assessing how to move forward can be difficult, and it might seem like a good time to jump ship. But all is not lost.
Taking steps in the right direction
When increasing test coverage becomes a priority, tools like rspec-jumpstart can help greatly. This gem dynamically generates something like a scaffold of tests for any code not already tested. It’s not a magic wand, but it’s the perfect starting point and particularly helpful in identifying untested code.
If you do have an upgrade on the horizon, there are some simple things you can do in the meantime by way of increasing test coverage to help mitigate the innate pain of upgrading.
One of the simplest ways to increase test coverage is to make a habit of writing even basic tests for any code that you work in on a given day, especially for any code added. But sometimes, testing alongside development is easier said than done.
For example, when on a tight schedule, either to deliver a promised feature or because you’re approaching the end of your client’s budget, skipping tests is an easy way to cut time.
It’s important to remember, however, that time saved here might end up adding much more time later in maintenance, bug fixing – and definitely upgrading. Using a tool like SimpleCov can help focus your efforts and make sure that the tests you are writing are hitting their intended targets.
Checking in on your test coverage before pursuing a Ruby on Rails app upgrade is a good example of examining the state of your app before jumping into major changes. A little planning will pay off in the long run.
