Before releasing an update to a website or application to public, one should always ensure that everything on the UI side is in order. This is usually a manual process: we deploy the site to the staging server where a designated tester (or the developer themselves) runs a thorough review.
Automating this type of tests will let you save time and avoid human errors.
In this guide, we will show you how to quickly configure a pipeline that will build your application, deploy it to the staging server, and perform automated visual tests in the staging environment. If everything is fine, the pipeline will deploy the application to the production server. In case any visual changes are detected, the pipeline will stop and wait for approval before the final deployment.
Build and deploy on every push
If you already know how pipelines in Buddy work, you can skip to the next step.
Begin with creating a pipeline that will build and deploy your application. If you haven’t done it before, here's a list of quickstart guides for the most popular languages and frameworks:
Visual tests in delivery pipelines
Once you have a pipeline that deploys your application to the staging server, you need to add the action for visual testing. The action compares the currently deployed version of your site with the previous one and, in case of any changes, it stops the pipeline and waits for the changes to be approved.
Select the Visual tests action from the monitoring section:
The actions lets you define the URLs that should be tested. In our case, it will be the address of the page on the staging server:
Now it’s time to add the deployment to the production server. If no changes are detected, the deployment will be performed automatically. In other cases, it will require a manual confirmation from the user:
The first launch of the pipeline will take screenshots of the current version. The screenshots will serve as the baseline with which the next versions will be compared. Upon approval of the changes, our baseline will be updated to the accepted version.
Once the tests detect changes, the pipeline will stop and wait for the approval. You can define who is permitted to accept visual changes in the action settings. By default, all project members who can run pipelines can also accept the changes. You may, however, limit the scope to individual developers, administrators, or a specific group of users:
During the acceptance process, Buddy will display all changes defined on the pages. The changes will be presented in the form of a comparison of the previous and current version of the page (difference, swipe, 2-up):
Once accepted, the pipeline will pick up where it's left and deploy the app to the production server.
A website may often contain dynamic elements, such as advertising banners. This part of the site shouldn’t be taken into account during visual tests. The excluded parts can be easily defined by entering their coordinates in the Options tab:
Note that for each URL you can define any number of excludes.
Selecting browser and resolution & advanced options
The action settings allow you to select the browser and define the resolution in which the tests will be performed. Currently Buddy supports Chrome and Firefox browsers.
You can also set
On top of that the action lets you configure:
- The acceptable pixel tolerance level. By default, moving an element by 1 pixel will cause the pipeline to stop.
- How many executions are kept in the history of changes on the website. The default is 30 executions.
The aim of Buddy is to lower the threshold to automation regardless of whether you're a seasoned developer or just began your front-end adventure. The tool is very simple to user per se and basically requires no explanation. We do recommend, however, to check out our documentation for real-life use cases that will help you quickly automate the most essential processes of everyday work. Also, don't hesitate to browse through our guides for inspiration and tips on CI/CD. There's also the live-chat should you have some concrete questions.
Thanks for reading!