We test, therefore we are

Our app has more than 60 000 lines of code; a volume large enough to make any small change in a single line risk messing something up. Our chief strength is automation. So we decided to automate not only the creation of ads (the app’s main goal), but also the internal development processes, such as testing. Therefore, we don’t need to be worried that a single altered line will ruin the app. Everything goes through multiple thorough stages of testing, from the early development to the moment the code is entered into the app. And even when the code is included in the app, testing still continues. 

After each GitHub commit, an automated test set is activated to detect any errors in the code. You can say that once each bit of code is handed over, it’s tested to make sure that it won’t break the app. If anything does go wrong (which happens, it’s a common part of the process), we receive a report on what happened and where. To achieve this, we use CircleCI to save ourselves the necessity of manually testing everything. Instead, we leave it up to the program and kick our feet up. Oh, and yeah—it also saves us lots of time. It doesn’t really matter which form of CI is used but we prefer CircleCI.

Independently of this, another set of tests is run at night to make certain that everything works as it’s supposed to, even when we’re not tinkering with the code. There are many ways for the app to break even when left alone, e.g. hardware malfunction or a change in the API of advertising systems. Along with these nightly builds, visual regression tests are run in our sandbox where all of the app’s visual features; more on that below.

Testing can be divided into backend and frontend tests, manual and automated tests, and many other combinations. Our developers mostly do backend tests to verify whether small bits of code are functional—but that’s a topic for another day. The second place goes to frontend tests which work with the app as a whole, simulating user behavior and checking whether to use conforms to the design. We use Cypress to do this, a program that’s proved invaluable when it comes to dealing with bugs. Cypress tests all “happy paths” in the app—the complete path from the creation of a data source to creating various types of campaigns and testing different ways of setting keyword and ad text generators, final synchronization, or Tuner operations.

Percy is another invaluable tool, used for visual regression testing. Practically speaking, this means that we mark places/pages/parts of the app for Percy to “snap” and save as reference images. As soon as the page’s content is changed—e.g. a component’s content or text changes, something fails to render or on the other hand too much is rendered—Percy lets us know and shows us the before and after. This allows us to see which components were changed and whether the said change is correct, or not. If it’s correct, we simply mark the new snaps as reference images and move on. If the change isn’t correct, we now know (or at least should) what needs to be fixed. We use this tool for our sandbox as well since that is where this type of testing truly shines.

A lot of people are scared of new challenges, especially those which take a lot of time to implement. Carefully creating a test environment and scenarios may be one of these challenges. Nevertheless, the time invested in testing and the related processes is well-spent indeed as tests save our time and prevent us from going prematurely gray. Don’t be afraid and give it a try. The results are truly worth it!