Using test branches helps you make isolated changes to a test without affecting the master version of that test. Thus, you can keep running a test as part of your scheduled regression suite while making changes to that test on a branch. By default, all newly created tests are saved to a master branch, unless specified otherwise. That way you can open the master version, make changes to it and save it to a branch (e.g. my_feature_branch). Saving test changes to a branch does not affect any other versions of that test and save a test to as many branches as you want. Once you are done working with a branch, you can merge it to master which will update the master version of all tests saved to that branch.

Use cases

When it comes to branching tests, there are four main use cases:

• Test development branches without impacting your core test suites
• Experiment with tests and get feedback without affecting the master test version
• Run two different versions of the same test across two different environments (e.g. dev and prod)
• Promote tests together with code across CI/CD environments

🚧

Branching limitations

• Snippets - no support for branching; updating a snippet on a test branch will update that snippet across all test branches and versions where that snippet is used.
• Snapshotting a test version to an environment is not yet supported. Once a branch is merged, all environments will start running that master version unless a different branch is specified.
• Visual tests cannot be branched

Branching tests

To save a test to branch, go to the mabl app and create or open an existing test, which will open the mabl Trainer. By default, you will see the master branch selected at the top of the Trainer from where you can create new branches and switch to existing ones.

Clicking to save your test in the Trainer will save all changes to the selected branch. You can also switch between branches to make additional changes and replay them in your local Chrome browser.

📘

Test branching consideration

Only changes to the test steps are saved to a branch. Changing the test name, description and other information outside of the trained steps will apply to all branches for that test.

Running branched tests

Running single tests

To trigger a single test run on a branch, go to the test details page, select a branch and click the RUN TEST button which will trigger a test run for the selected branch.

In the sidebar that appears, select the browsers, application, and environment you'd like to run your test against. You can also add credentials if you need them.

If you're testing a preview environment, or any testing environment with an arbitrary or changing URL, you'll want to use the URL override option here. You'll still need to select an application and environment to run the test, but the URL you type will override the URL above once the test is run. Just click the run button at the bottom and then click the results when they're available.

🚧

Basic Auth and HTTP headers support

Please note that basic auth and HTTP headers are not supported in a single manual test run as described above. Follow the steps below to take advantage of this functionality if your application or testing requires it.

Running plans

You can also run a plan on a branch by going to the plan details page and choosing to run the plan with overrides from the RUN PLAN button menu. You will be able to select a branch for the plan run and override the testing environment URL, if needed. If a test from the plan doesn't have a version on the selected branch, the plan will run the master version of that test. Thus, you can run your complete regression suite against a development environment, make changes to a branch and merge the branch once you are happy that both the tests and app under test don't have any issues.

If a plan or a test run was on a branch, you will see it marked with a badge indicating the respective branch name.

📘

Branches and plans

Plans are not branched but they are branch aware. All plans currently run off of the default master branch where tests edits are saved to by default. This means the plan will always run the latest version of the test merged to master. And if a test does not have a version on master yet, you can still add it to the plans you want it to end up in and the plan will skip it by default.

Managing branches

You can see a list of all your test branches if you navigate to the Tests > Branches tab in the mabl web app. From there you can create and delete branches.

Viewing branch details

Clicking on a branch in the Branches tab brings you to the Branch Details view, which provides a summary of the tests and flows on the branch as well as critical information including:

• The current version of the development branch along with the author and timestamp
• The current version of the master branch along with the author and timestamp
• Steps changed on the development branch compared to the master branch
• Warning of potential conflict if changes have been made on master since branching off

Merging a branch

To merge a branch into master, use the Merge button on the branch details page. You are presented with a warning modal with the suggestion to resolve conflicts if you try to merge a branch that has potential conflicts. At this time, the only way to resolve conflicts is to view the differences between the two versions and reconcile manually in the trainer.

If you have no conflicts on your branch, you will see the following confirmation.

🚧

Merging limitations

• You can only merge a branch into master and cannot choose a different branch to merge into.
• At this time, resolving conflicts can only be accomplished in the trainer.
• Merged branches older than 30 days do not have access to the Branch Details page.
• API tests can be branched, however viewing the differences is not supported

Reverting a merge

Sometimes the merged version of a test will result in unintended consequences and you will need to revert to a previous version of that test. Currently, you can do so by going to the test change history, selecting an older version and saving it as the latest version for that test.