A Case Study in Updating Front-End Testing Frameworks

You have a website. It’s old. Your web engineers speak disparagingly of its outdated testing framework, and despair new changes for the risk they introduce. They claim the difficulty of testing slows down development and causes customer-visible mistakes — especially in the most complex, impressive aspects of the web site.

At Urban Airship, this was the position we found ourselves in a year ago, even as we were gearing up to redesign the user interface (UI) for our flagship tool, Urban Airship Engage. We believe that our approach to transitioning between the old and complicated to the new and simple provides a worthwhile case study in technical decision making.

Want to get the details on how we did it? We've documented the approach our engineering team took. It’s now available to read on GitHub. The case study includes:  

• Why our legacy testing framework needed to be updated: We describe in detail the limitations of our legacy framework and the issues driving the need to upgrade.

• Our process for proposing changes: Borrowing the concept of the “pre-development review” process from the construction industry, Andrew and Nate describe the process we set up to screen proposals for problems and involve the whole team in  decision-making.

• Requirements for our JavaScript testing setup: Without clear requirements, it’s impossible to evaluate where we stood or possible candidate solutions.

• How we decided which front end testing tools to use going forward: We completed a survey of the field of available testing tools available at the time (about a year ago), describing the strengths and weaknesses of each tool. Many of those same tools still exist today.

• Lessons learned: From making it easy to switch dependences to the importance of writing isolated code that can clean up after itself, read about the lessons we learned during the process.

• The testing flow this process enabled: We describe the fruits of our efforts — our framework no longer gets in the way of swapping out build systems or test runners.

Head over to GitHub and get all of the nitty gritty details.

Our hope is that individual contributors find the technical discussions of various available (circa 2015) testing tools informative, and that managers find the process we used to come to our new framework an example of healthy, defensible, collective decision making.

What to see how it all turned out? Sign up for a starter edition of Engage today. You'll see our re-designed Composer tool – and see why developers choose Urban Airship for push notifications.