How to integrate BitBucket into your Visual Testing

Applitools In Your Bitbucket Workflow

As you may know, Applitools Eyes supports multiple branches, each of which can consist of multiple test baselines. Eyes supports creating a new branch based on an existing branch, independent updates to the baselines in each branch, comparing branches to detect conflicts, and finally merging of the baselines in branches. This is all designed to fit into a trunk-and-branch development workflow.

With our  new Bitbucket integration included in the Applitools 10.7 release, you can now build workflows around Bitbucket that incorporates Applitools baseline images. The major capabilities in the integration include:

• Applitools visual UI tests are automatically configured to use and save baselines in branches whose name is derived from the Git branch names.
• All visual UI tests that are in a specific CI build, are automatically batched together, with a batch name that includes the Git commit information.
• The Bitbucket pull request panel includes a status indicating the latest visual UI test results and merge status.
• When the user initiates a Bitbucket pull-request merge, this will also trigger an Eyes branch merge.

Effectively, Bitbucket workflows drive both the application code as well as the Applitools Eyes repositories.

Bitbucket Cloud or Self-Hosted

The integration works with both Bitbucket Cloud as well as Bitbucket Server or Bitbucket Data Center. The primary difference between the two setups is how the CI system lets Applitools know that a build is complete. For Bitbucket Server or Bitbucket Data Center, you need to tell your CI solution how to notify Applitools explicitly with a build status notification. That step is unnecessary when you use the cloud-based solution.

For the cloud integration, you simply need to point to the Bitbucket server and then identify your team’s repositories. There are a few other details listed in our documentation. For the self-hosted solutions, you need to configure your CI solution (CircleCI, AppVeyor, Jenkins or Bamboo) so that it sets the environment variable APPLITOOLS_API_KEY to your Applitools API key. Easy.

For the self-hosted solution, you will need to point your Applitools solution to your Bitbucket server and identify your team’s repositories. You will also need to allow traffic from the Applitools Eyes service to traverse your data center (and, potentially, your corporate) firewall. Again, the details are in our Bitbucket integration documentation

Latest SDK Includes Batch Calls to Applitools

To run the Bitbucket integration, you need the latest SDK for your UI development language of choice. SDK update are available for the following languages:

• Java
• Javascript
• Ruby
• Python
• C#
• PHP

The SDK includes a call for APPLITOOLS_BATCH_ID, which links the Applitools run to the Git commit information. From this link, the images collected by Applitools Eyes link to the branch of code being built and run – or integrated into another branch.

Bitbucket and Applitools in Operation

So, how does this all work in practice?

The Eyes Bitbucket integration is based on the Bitbucket pull request. When there is an open pull request, Eyes adds the following functionality to your Bitbucket workflow:

1. When your CI initiates a build that includes an Eyes test, Eyes detects that the run is associated with a Bitbucket pull request and will search for a baseline to use as a reference. Eyes will check for a matching baseline in the following order:
   1. On a branch that corresponds to the repository name and source branch defined by the pull request.
   2. If there is no such branch, it will create a branch and populate it with the latest baseline for that test from the repository name and target branch defined by the pull request.
   3. If there is no such baseline the test will be marked as “New”.
2. The Bitbucket Build panel will include two Applitools specific lines.
   1. tests/applitools will show the results of all tests related to the specific workflow and whether are still in progress, and for completed tests, whether they have passed, failed, or need to be evaluated. tests/applitools is a link to take you to the Applitools Eyes test results to resolve any failing tests in the Eyes UI.
   2. scm/applitools shows the results of the branch merge between source and target results. An alert icon means that there are conflicts, while a green checkmark icon means the merge passed. scm/applitools is a link to the Merge Branches screen in Applitools Eyes Test Manager from which you can inspect any reported conflict and take steps to resolve it.

Resolving Conflicts in Bitbucket and Applitools Workflow

Once you have established the integration for a given application, a pull request automatically launches Applitools Eyes for that particular branch activity. When the resulting build process run smoothly and the Build panel shows no errors, move on to your next task. Otherwise, you need to resolve the conflict.

Fortunately, this work is easy to do inside Applitools.  In this case, you check the image as tied into source or target baseline to determine whether you want to update the baseline to the source version, update the baseline to the target, or identify a new unexpected behavior that needs further development.  It’s the work you do regularly with Applitools Eyes – just limited to the branch activity in question.

By using this integration, you link your Applitools Eyes visual testing with your CI workflow. You automate the branch names for your Applitools eyes results, and your Bitbucket pull requests drive the workflows that allow you to identify and resolve differences. You can ensure tight integration between your functional tests in your favorite language and testing tool and the visual results captured by Applitools Eyes.

For More Information

Documentation about Applitools-Bitbucket Integration

Blog: How to Make Jira Easier to Use with Integrated Visual UI Bug Tracking

More from Applitools: Request a Demo, Sign Up for a Free Account, or visit our Tutorials.