Testing in Motion

Or “How Unit and Functional tests let us upgrade our framework from June 2014 to January 2017” (about 25 years in modern PHP!)

A project we shipped a few years ago rolled back in lately with a laundry list of new features to add.

We use Laravel PHP for our API based projects which has had some amazing additions in the last 2.5 years, and some awesome new tools in the ecosystem (we want to use Backpack for Laravel).

After purchasing a Laravel Shift package to upgrade our 4.2 project to 5.0, we started working down the list of remaining work to do the upgrade, all the time keeping one eye on the functional tests running continuously in the background.

The pull request (changes made by Shift) changed 1849 lines across 305 files. That’s about as big as a change gets… And it’s on a production application!
How many times have you requested a tiny change in a project that breaks everything? Read on.

First, 0 tests were passing, and there was errors everywhere. That’s OK! That’s what we have the tests for. Midway down the list, about half the tests were passing! Once all the “4.2 to 5.0” steps were carried out we had only a few failing tests for functionality that has fundamentally changed that we need to rewrite.

These are complex business rules where hooked functionality causes a cascading data update effect. Think ‘value A updated in table A automatically updates value B in table B and triggers a cache rebuild’.

Our tests that GET/POST to ajax endpoints, load user dashboards and check for expected data, and pull things from the database to check values are as they should is what made this upgrade possible.

We know once the tests are passing, our app is running perfectly in every way that the tests are checking.

Over the next few days, we’ll spend a few hours running through the application ourselves as well, to find places we might be missing tests and actively hunting for broken functionality. Before we fix it, we’ll write new tests and add them to the suite, so anything we find will never be broken again.

The changes won’t make it to production for a little while yet, but we’re confident it’s going to be smooth sailing. The tests prove it.

Testing on an ongoing project is a never-ending task. Any bug that appears, any new piece of functionality will have one or multiple tests added to the library so the software is forever improving.