When a Testspace project is created, it is connected to a GitHub repository. Each space under the project maps to a corresponding branch in the repository. Spaces are automatically created and deleted based on the repository activity. When a space is created it is set in a
- Release spaces are for test execution
- Sandbox spaces are for test development
A repo's default branch (i.e. main) is always a
release space. All other branches are
sandbox spaces unless explicitly configured. The example configuration below sets all branches with the string
release_ in its name as a release space:
- "*release_*" # i.e. "release_56" branch used for test execution
There are two branch flows recommended when testing using Testspace:
Main flow is based on the GitHub flow. The default branch, typically set as
main, is used for testing all releases, with branches created from the default branch used for working on new test development.
Main flow is based on continuously testing using the default branch (i.e. single release space).
Update the branch description to reflect the name of the release being tested.
When a release has been completed/deployed it is recommended to tag the repo and pin the results adding a link to the commit id representing the repo being tested.
It is common to follow the same release naming of the repo being tested.
If a hotfix patch is required to be tested a
release branch can be used. The following is an example of leveraging a tag.
$ git checkout -b release_42.4.1 tags/v42.4
$ git push origin release_42.4.1
Note that the
release branch will require configuring:
Release flow is loosely based on the Gitflow, where a release branch represents the testing for a specific release of the system under test. This
flow is especially useful when multiple releases are required to be maintained at the same time.
Release flow is used when multiple releases are required to be tested and maintained.
A common practice is to name the branch based on the system under test release name.
To support the
Release flow the non-default branches requires configuring:
When branching, if the
base branch has test results, the results will be copied as a new baseline for the space corresponding to the newly created branch. The baseline suites will be carried forward on subsequent test sessions.
To assure proper baseline of test results, create your new branch from the appropriate
base branch with results. For example:
git checkout release_abc
git checkout -b release_def
git push origin release_def
The new branch (i.e.
release_def) will reference the current
release_abc results as it's baseline. In the next session, all tests not executed will be carried from the baseline, the
release_abc test results at the time of branching.
A space's results can be reset, removing all history of previous test sessions, including metrics. To start with a clean slate use the hamburger menu of the space and select
To avoid carrying a base branch's previous status use the
Following the same process for code development, a branch -
Sandbox space - should be used to isolate new test development without affecting other branches in the repository. Using a pull request enables others to discuss and review potential changes, follow-up with additional commits, all before your changes are merged into the base branch.
Sandbox spaces do not persist spec runs.