There are two branch flows recommended when testing using Testspace:
github.com/org/repo/branches └─ main └─ testdev/abc_tests └─ testdev/def_tests ..
Main flow is based on continuously testing the
main branch, which is assumed to always being in a deployable state (or at least ready for system testing).
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.
Tip: Follow the same release naming of the repo being tested.
If a hotfix patch is required to be tested a
release branch can be deployed based on a tag.
$ git checkout -b release_42.4.1 tags/v42.4 .. $ git push origin release_42.4.1
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 flowis especially useful when multiple releases are required to be tested separately.
A common practice is to name the branch based on the system under test release name.
github.com/org/repo/branches └─ main └─ release_abc └─ release_def .. └─ testdev/def_tests ..
Branches are used for testing releases of the system under test.
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 result carrying make sure to create your new branch out of 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 (
release_abc result at the time of branching).
Once a branch is deleted within GitHub the corresponding space containing
results will also be deleted.
Don't delete branches with test results you want to keep. A branch deletion results in the corresponding space being deleted.
Note that if the
base branch has no test results, no previous results will be carried into the newly created branch. For example, creating a branch using a base branch that has no
.testspace.yml file will establish a new empty baseline.
Test development should be done using a separate/isolated process following good development practices. When developing new tests a sandbox space should be used. More specifically create a "feature" branch off the
main branch (or latest release branch) and use a
pull request for review by your peers before merging back into the base branch.
pull requestis open you can discuss and review changes with your peers.
$ git checkout main $ git checkout -b feature/abc_test .. $ git push origin feature/abc_test
Tip: Consider adding a Testspace session link in your pull request to aid in the review.