Branches and version control

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.

Testing with branches workflow.

Testing with branches workflow.

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.
  • Merging branches - there is no conflict resolution and the branch version effectively replaces master
  • 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.

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.

Test overview with branch selector and "run test" button.

Test overview with branch selector and "run test" button.

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.

Running a plan with overrides: branch and URL.

Running a plan with overrides: branch and URL.

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 Tests > Branches tab in the mabl web app. From there you can create, merge and delete branches.

A list of test branches in mabl.

A list of test branches in mabl.

Merging a branch

To merge a branch into master, use the Merge button in the branches table. The merging action will simply convert the branched version into master for all test and flow versions on that branch. Thus, for the time being, please use extra caution when merging a branch.

Merging limitations

At present, you can only merge a branch into master and cannot choose a different branch to merge to. Also, if changes were made to master after a branch was created, merging that branch will effectively discard all changes made to master that are not explicitly added to the branch.

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.

Updated 11 months ago

Branches and version control

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.