Testing should be an indispensable part of developing any product. Sometimes it’s circumvented, sometimes viewed as a necessary evil so that we can get our invention to people. And other times, testing can be fun, and if the processes are set correctly you don’t need to even know it’s going on. Which is our case.
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.
Cypress and Percy are the bestest among besties
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.
You, too, can be involved in testing!
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!
We test, and you should too;
We use CircleCI, Cypress, Percy, and a whole lot of backend tests;
You might be intending to create campaigns that will promote your products as Christmas gifts. The number of Christmas gifts buyers, of course, drops down massively after Christmas Eve, thus generating such campaigns has no sense any more. To prevent the need to turn on your PC on Christmas Eve in order to end a campaign, we added the possibility to time limits for ads. This option applies to both, generating and non-generating of advertisements. Moreover, we tried to make it as easy as possible for you.
The more space the advertisement occupies, the bigger the chance that it will get noticed. This is something that the people at Google Ads are well aware of, so they came up with another text ads extension — a third headline and second description. Of course, this new feature didn’t escape our attention at PPC Bee, and we reflected the changes in the new version of our app.
Another product meeting, Wednesday afternoon, June 2019. I and Pavel, my UX co-pilot, were staring at each other, waiting to see who’d be the first to say that once again, we plan to load an A-bomb on a biplane. The plan to add Facebook campaigns, an image editor, and other functions made us excited. What worried us, though, was the app’s interface—it was already hard to navigate and users were finding it more and more difficult to look up the functions they needed.