So far, in this tutorial we have
- manually invoked a GitHub workflow to publish pre-canned results
- executed a Hello Manual test spec
- implemented and executed new test specs from scratch
This section of the tutorial will focus on leveraging branching when developing new test specs.
Let's again implement some new test specs, but this time use a
The first step is to create a branch. Let's call it
git checkout -b sandbox/mytests
Note that the GitHub UI can also be used to create a branch.
Using the same process as the previous section, go ahead and create a couple of test specs, each consisting of multiple cases.
Once complete commit and push the changes:
git add . git commit -m "New Tests" git push origin sandbox/mytests
Now go to your Testspace project. You should see a new space called:
- By using a branch name with the
sandboxsuffix, the branch will be set as a sandbox. A sandbox branch is used for new test development, not for "official" test execution. The sandbox naming convention is configurable.
- The previous results are automatically carried to the new branch.
It is often a good practice to evaluate (pre-run) the newly developed test specs. The completion of the test session containing the new specs is often not required. This step is really for vetting the new tests before generating a pull request.
Because the test specs use plain text, it is easier for non-testers to participate in reviews. Testspace leverages the power of GitHub's Pull Request feature to facilitate peer review.
Testspace leverages GitHub's Pull Request to facilitate peer review of test specs.
Create a pull request for the
sandbox/mytests branch - into
Once a pull request is open, Testspace reflects this state along with the name of the pull request (i.e.
Remember it is not required to complete a Test Session. Thus, the
Tests counts might not change. It is often a good practice to include a link to the active test session in the pull request, allowing reviewers to see the full rendered test instructions.
Once the pull request is
approved, the branch can be merged into the default branch and deleted.
The corresponding space of the deleted branch will be automatically removed in a day or two.
Testspace supports the widely accepted development flow using branching and pull requests, in support of Manual Tests as Code.
New test development should be done using a separate/isolated branching process, thus following good development practices